On Wed, 2010-11-10 at 16:30 +0100, Peter Zijlstra wrote:
BTW, the sub buffers is just an implementation detail. I suspect that
we'll have to end up with something that splits the buffer up. Whether
we have 'markers' or something else. They all break down the buffer into
a "sub-buffer".
I was thinking about this more. I guess it can work if the reader always
goes the opposite direction of the writer. It's just any user that uses
this will need to cope with it. I would personally like both methods
implemented. One as the "broken design" (as you put it) which removes
the burden of sorting from the user. But the "fast design" which
requires the end result having to be able to sort the buffer.
Sure.
yep.
But lets make this somehow generic, where it can be used by all sorts.
Sure.
Also, lets not focus now on implementation. Let's try to concentrate on
what we want the tools to be able to do.
For example, I would like:
Very small entries, and pick and chose what I want in my entries.
A way to read it fast to a file or over the network (splice).
The read backwards seems like a cool idea, but I would not want to throw
away the read forwards part either.
How we implement this, we can work together on.
-- Steve
--