As far as I can tell, the only thing on that list not solved currently
by `pipes` is leftovers, but I will be releasing that very soon.
Hello everybody,
I'm trying to formulate the stream processing problem, which doesn't
seem to be solved fully by the currently existing patterns. I'm
experimenting with a new idea, but I want to make sure that I don't miss
any defining features of the problem, so here is my list. A stream
processing abstraction should:
* have a categorically proven design (solved by iteratees, pipes),
* be composable (solved by all of them),
* be reasonably easy to understand and work with (solved by conduit,
pipes),
* support leftovers (solved by conduit and to some degree by
iteratees),
* be reliable in the presence of async exceptions (solved by conduit,
pipes-safe),
* hold on to resources only as long as necessary (solved by conduit
and to some degree by pipes-safe),
* ideally also allow upstream communication (solved by pipes and to
some degree by conduit).
* be fast (solved by all of them).
Anything else you would put in that list?
Greets,
Ertugrul
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
