Gabriel Gonzalez <[email protected]> writes: > In your specific case, is the client of your push-based service a > browser or another server?
Mostly browsers. [Sort of digressing from the thread...] It's a chat-like thing, so the browser first receives a backlog, and then switches to streaming events. Sometimes the browser also POSTs a command. Everything is tied together with AMQP, the message bus protocol. This was all pleasingly nice to express with horizontal and vertical composition of pipes. The "main loop" is something similar to: | runEffectsConcurrently | ((do yield Starting | each (oldEventsFrom store) | AMQP.readFrom bus >-> decoder) | >-> toChan allEvents) | (fromChan allCommands >-> encoder >-> AMQP.writeTo bus) I'm using a number of TChans and TQueues as sources and sinks for my pipes, which is convenient for adapting to things like AMQP, WAI, etc. With this style, I've found that I can keep the basic data-flow structure of the server actually readable from the main function. Instead of an obscure state machine with different modes and callbacks and "handlers," I just write down my intention as a tree of concurrent pipelines. So far my error handling isn't great. Erlang has quite far-reaching conventions and support for this, but I'm not sure how to organize it in Haskell. (I'm a little sad about how we generally try to be declarative, total, and careful, and then at any point some random error might crash the whole program... Of course, it's not our fault, it's that messy I/O world out there...) Anyway, pipes are fun, so thanks! Maybe we should have a "what are you using pipes for?" thread... -- Mikael Brockman @mbrock -- You received this message because you are subscribed to the Google Groups "Haskell Pipes" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected].
