Closed christianbundy closed 6 years ago
reflecting on this a while... async codecs don't make sense: a codec is just a decoding format. that we are doing decrypting inside the codec in secure-scuttlebutt is an ugly hack that only works because decrypting is sync. I don't want to expand that hack by making codecs officially async.
However, we could add an async map step in flumedb
... it would wrap the log, affecting the output of log.stream
and log.get
via an async function... then it would work with any sort of flumelog, not just flumelog-offset
(note: I am working on http://github.com/dominictarr/flumelog-random-access-file which has a different format and is much faster than flumelog-offset
)
Thanks! I'm not familiar with flumedb, but I'll look around and see if I can get another prototype working. Thanks again for taking a look at this!
This resolves #13 by wrapping codecs in
Promise.resolve
orPromise.all
for batch operations, and adds an async test which is just theflumelog.js
test withsetTimeout
. This shouldn't have any effect on synchronous codecs.I don't think we're currently handling codec errors, so I've left
reject()
unused, but if there's an elegant way to handle promise rejections I'd be happy to implement it.