Unlimited ChannelBuffer by writing/reading to disk #176
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/znc#176
Reference in new issue
Block a user
I would really like to be able to set my ChannelBuffer to unlimited and then optionally define if I want that buffer to be written/read from the disk or from RAM.
When the log module and that write/read to disk option is enabled, ZNC could just read the appropriate files from the moment a client disconnected and use that as the scrollback that is forwarded to the connected client.
Another variant would be to define a limit of lines that may be stored in RAM before the rest is written to disk, to reduce access for low activity channels and allow an unlimited ChannelBuffer for high activity channels.
--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/98427-unlimited-channelbuffer-by-writing-reading-to-disk?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).I'd say, current buffering should be moved from core to a module, that would make it easier to implement this as a module too.
I've always wanted to move buffers into a module! No idea how that would work.
You could have plugin types of sorts. Or plugin roles.
So you have a buffer module type, and only allow one module of that type to be loaded.
Since you know it is of that type, you can provide extra api calls into the module.
The other option is providers, so when a module is loaded it registers itself to specific events and announce it has specific callbacks.
On Jan 2, 2013, at 7:51 PM, Kyle Fuller notifications@github.com wrote:
I would love to see something like this implemented too. I am not a software developper, though.
Previously a Quassel user, I do recollect this feature available there. When scrolling back, it would reach out to the Quassel core and fetch older data.
When I saw the log module in znc, I had the impression that it would work the same way. But from this bug report, and my feature verification, that is not the case. Would be nice to see this feature implemented.
This is probably the top thing I wish ZNC had. Not very scalable to keep all the buffer messages in memory. Plus, writing to disk can allow for virtually unlimited amount of buffering, a la Discord.
Unlimited buffer would make clients unhappy, which will get all that buffer upon connection. So it needs a special protocol which sends only part of buffer, then, maybe, another part.
To make this a bit more striking:
Do you really want ZNC to dump 1 GiB of playback to your client every time you connect to it? How long will it take for all of that to be sent to the client? What will the client do with all of this data? (Besides being unusable for minutes)