Hello, as I start to play with Lamson and as I have been spoiled by Mongrel2 flexibility in handling the communication channel asynchronously between the clients and the workers/handlers over zmq, I wonder if it would be hard to apply the same principles with Lansom. Would it be crazy to imagine that you have workers handling each state in Lansom and pushing back the answer asynchronously to Lansom? In the same way Mongrel2 parses the request and keep track of the connected/disconnected and protocol for the client, Lansom would parse the email and just dispatch based on patterns and states. I have seen I can play with the queue at the Lamson level but for what I understood, the connection client <-> Lamson is not kept to push the answer (for example a bounce) while defered. Yes, this is because now I want to have webapp and emails for my service and starting a zmq worker to handle the emails would be great as at the backend level I would have an homogeneous communication system without the need to share a maildir queue over nfs or things like that. Just a maybe stupid idea but your feedback is welcomed, loïc
On Fri, Aug 05, 2011 at 10:51:43AM +0200, Loic d'Anterroches wrote: > Hello, > > as I start to play with Lamson and as I have been spoiled by Mongrel2 > flexibility in handling the communication channel asynchronously between > the clients and the workers/handlers over zmq, I wonder if it would be > hard to apply the same principles with Lansom. I've contemplated a Lua+Zmq version of Lamson for a bit, with a similar design, but I've been lazy. It would work, and could be easier to work with, but I haven't stepped into that realm yet. If you wanted you could probably use Lamson to prototype this. -- Zed A. Shaw http://zedshaw.com/