Sorry but the "reloaded" brand is already used by another JBoss project managed by Thomas Aardal to allow "old" JBoss client jars to be used with newer JBoss releases ;)
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: lundi, 16. juin 2003 21:08 > To: [EMAIL PROTECTED] > Subject: RE: Antwort: RE: [JBoss-dev] JBossMQ rewrite > > > As Bela and I have recently discussed with Tom Elrod, we all > think that > exposing JavaGroups as a transport of the remoting framework > is indeed the best > approach. However, I struggle with how the client-server > nature of the > remoting framework maps to the client-client nature of > mulicast. I think this > can indeed be overcome. However, as Tom doesn't have much > time to spend on it, > I think the road I'm gong to go down is to code directly to > JavaGroups right > now, and abstract it later. > > However, the real important point here FOR EVERYONE TO GET is > that the > multicast implementation is just ONE implementation of the > client-side JMS > interfaces. We will also support the traditional client-server based > implementation that the new code is building toward. The > only reason I'm even > talking about the multicast stuff is because Bela showed me > just how JavaGroups > makes it so simple to implement and it will give us an > opportunity to get > something out the door in short order. Additionally, > multicast will always > provide better performance for pub/sub then a traditional > client-server > design. So for clients that want in-firewall messaging that > is super fast, the > multicast stuff will best serve their needs. For clients > that need Internet > messaging, etc. the traditional design will be used. > > We are VERY focused on building a best-of-breed JMS > implementation. The > current code causes us pain and that is all the motivation we > need. I was very > encouraged to talk to the guys last week and gather ideas. > Andrian Brock is > brilliant and has all sorts of ideas for the new JMS codebase > that have all > grown out of his dealings with the old codebase. We will not > repeat the > mistakes of the old codebase which is why we're starting anew > from scratch. > > I'm going to get the project page on the website set up to > better communicate > the plan (which is something I should have done long ago) > over the next week. > > Oh, and to address Marc's comment on the "reloaded" thing... > that is just a > code name for now--it sounds better then saying "rewrite." > The branding is > clearly JMS/JBoss. > > Thanks, > > Nathan Phelps > JMS/JBoss Project Lead > JBoss Group, L.L.C. > > > Quoting Bill Burke <[EMAIL PROTECTED]>: > > > Nathan's design will not be based on JavaGroups, but will rather use > > JavaGroups as one type of transport mechanism. I would > rather see JBoss > > Remoting used as an abstraction with JavaGroups as a plugin > rather than > > JavaGroups at the center of things. > > > > BUT....don't let this requirement hold you up from getting > a first iteration > > in place. > > > > Bill > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > Behalf Of Bela > > > Ban > > > Sent: Monday, June 16, 2003 1:12 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite > > > > > > > > > > > > Hi Ulf, > > > > > > > (2) message redelivery / message throttling clustering > / failover > > > > > > > > > since Nathan's design is based on JavaGroups, these issues are > > > JavaGroups issues: > > > - Message retransmission is handled by JavaGroups. > > > - Failover: what do you understand by failover ? > > > - Throttling: we are working on a multicast flow control > protocol, JG > > > currently ships with one, but it has a number of bugs and > needs further > > > work. I'm also working on a new flow control protocol. > Also, note that > > > you can run JG with TCP as transport, then you > essentially have the > > > classic JMS client-server implementation. > > > > > > > > > > (3) messaging system monitoring / administration > > > > > > > > I there a way to participate in the your ongoing rewrite ? > > > > > > > > > Give us some more time; Nathan essentially designed the > serverless JMS > > > last weekend... > > > > > > > > > -- > > > Bela Ban > > > http://www.javagroups.com > > > Cell: (408) 316-4459 > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.NET email is sponsored by: eBay > > > Great deals on office technology -- on eBay now! Click here: > > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > > > _______________________________________________ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: eBay > > Great deals on office technology -- on eBay now! Click here: > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
