I took a few hours today and wrote two small components:

• an in-memory flumelog that acts like flumelog-memory without the filename argument
• a small flumeview (which depends on the above flumelog) that just converts each item to boolean with !!

They're both impressively useless, but I feel like I have a much better handle on how things are working under the hood. My log supports deletion via flumelog.del(), but I'm unclear on two details of the implementation:

since

Is since meant to track the number of messages in the log or the number of operations executed? Having flumelog.del() bump since seems to make the most sense, but I don't want to overload any semantics.

deleteSink()

Speaking of overloading semantics, I'm thinking that a theoretical flumedb.del() would work like this: check for flumelog.deleteSink(), if exists then pass the { seq, value } item to be deleted, and if it doesn't exist then run flumelog.destroy() and force a full rebuild.

This would give us an optional deletion method that matches the creation method, the only problem is that it changes the semantics behind flumelog.createSink() so that "create" is a noun rather than a verb.

I was originally thinking flumelog.del() or flumelog.delete(), but I'm really enjoying the createSink() pattern and I think the consistency would be nice. With that said, I don't have any strong opinions on how this is named or implemented.