powered by Jive Software

Just a few thoughts

  1. What would the CM be in charge of besides obviously managing the connections?

I think it would be helpfull to roughly itemize what each component would be in charge of and what sub-components would comprise each. I can see the CM needing at least an authentication manager connected to it.

Aside from making the tcp connection itself, depending on the authentication provider, authentication is probably more of an expensive operation than anything else. Taking care of that on the CM makes sense, but then each CM would need a handle on an authentication manager and it’'s respective configuration and policies.

I guess what I’'m getting at is what core components stay in ‘‘Core’’?

  1. Do we need a new protocol and JEP for this? It really seems almost implementation specific as to how to distribute the load of concurrent connections. Would we create a JEP for XMPP clustering and failover next?

  2. Instead of a CM protocol, what about RMI and core services plucked out of JNDI?

Code could generally stay the same, just getInstance()s could be re-implemented.

just my 3c,

Rob

  1. What would the CM be in charge of besides

obviously managing the connections?

It will manage approx. 10k client connections and a smaller number of connections (perhaps just 1 initially) to the core server. It will also have to deal with xml validation and basic routing from its client to the core server. There will likely be a transformation of the on-the-wire format for performance reason between CM<->JM

I think it would be helpfull to roughly itemize what

each component would be in charge of and what

sub-components would comprise each.

Agreed, I think this will come after some work on the protocol.

I guess what I’'m getting at is what core components

stay in ‘‘Core’’?

Everything, JM must still work out of the box, it will be extended to handle additional connections/routing for ConnectionManagers.

  1. Do we need a new protocol and JEP for this? It

really seems almost implementation specific as to how

to distribute the load of concurrent connections.

Would we create a JEP for XMPP clustering and

failover next?

Good point. A reference to existing JEP is useful for comprehension purposes, whether its gets adopted at Jabber.org is another story.

  1. Instead of a CM protocol, what about RMI and core

services plucked out of JNDI?

Code could generally stay the same, just

getInstance()s could be re-implemented.

I think this would add too much overhead. I am not convinced that RMI is suitable for the kind of high throughput/connection management we want to achieve.

just my 3c,

+1c

Conor.