>If you liked that, also have a look at Spread: > >http://www.spread.org/ > >The messaging engine (daemon) isn't written in Java, but it's very >fast and efficient, and runs on all the popular OSs. The Java clients >connect to it via TCP sockets, so the clients can be pure-Java. The >License is similar to the Apache license, and unlike JavaGroups the >engine does know to fall back to using TCP unicast when multicast is >not available. It's been around for quite some time, too.
We speak about spread some times ago but the licence wasn't Apache at this time, and yes it's another good Broadcast system. Good point it support native and java. >What I'd like to do at some point is take Filip Hanik's TC4 session >replication code (looking nice!) and make it switchable to use either >Spread or JavaGroups, or other communication mechanisms for keeping the >session data in sync. Pluggable messaging back-ends.. > >FWIW, I'd like to see the in-memory session replication code as part >of TC4 itself, with a pluggable messaging layer API that allows >a separate messaging system to be used. But, if people decide that >it's better suited to j-t-c, then that's okay (not quite as good, IMO), >but I'd still like it to have a pluggable messaging layer API. Did the session replication and propagation is something which could be usefull for TC 3.3/4.0 ? If so, it'll better to have it in jtc. And since you point us that there is at least 2 solutions, javagroups and spread, it's another reason to have it in jtc where we could add others implementations.... -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
