Marc Schier wrote: > You do not want to use SEDA/Sandstorm in its current materialization. It's > a horrible codebase and has nothing remotely to do with COP. Two words: > research project. The underlying theory is very well thought through, but > the execution is based on research hacking (to prove the threory).
ok. > Berin > did a good job factoring out some concepts into the event package on top of > which I tried to build a framework and managing service. Because it handles > a lot of underlying things for you it's going more into the heavyweight > direction. Unfortunately there did not seem to be much interest, so I put > it off, since I am going to start a new job soon. can you elaborate on this (heavyweight direction)? if I'm going to undertake this, then I'll most probably need something more lightweight and I could try to implement something more lightweight... > BTW. You should also > consider this difference: JMS = distributed based, SEDA = not-distributed. > Also, an app server you are building with SEDA has the characteristic of > only running in one thread, whereas conventional app servers utilize one > thread per connection and therefore will run out of resources at a specific > number of concurrent connections. Ok, this gives even more reason for embedding Phoenix/Avalon inside MDB. This way the system can still be distributed at JMS level, but can take advantage of SEDA concepts at single application (MDB) level. Neeme -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
