mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bernd.fonderm...@googlemail.com>
Subject Re: [vysper] multiple resources/SessionContext per connection?
Date Tue, 08 Sep 2009 07:47:41 GMT
On Tue, Sep 8, 2009 at 01:41, Fernando Padilla<fern@alum.mit.edu> wrote:
> Hello.  I'm looking over the code base and like I said before, I think it
> looks great.

Thank you! :-) Great way to start a mail. :-)

> I have a question that I can't answer for myself just yet (since I'm not a
> mina expert it's hard for me to digest all of the Io/Codec/Protocol
> handlers).  The question is, how hard could one connection support multiple
> resources or SessionContexts associated with it.
> In XEP 0193 (incorporated into RFC3920bis), it says that from one
> steam-connection, the client is allowed to bind to multiple
> resources/sessions.

yes, and this is currently supported by vysper...

> And then in XEP 0225, they use this to have external
> components bind to the server (instead of the old XEP 0114), and I believe
> this could be used by federated servers too (not sure if that is mentioned
> in XEP or not). (urls are below)

... but I don't see how XEP-0225 requires binding multiple resources.

> Since Vysper doesn't have XEP0114 yet nor really support federated servers
> yet, I would vote to go straight into supporting 0193/0225.  I think this
> would make vysper more powerful in the long run, as well as having a cleaner
> more consistent code base...

Maybe. But it is still experimental. This means, that every components
implementing this protocol must be changed when the protocol changes.
But if there is somebody eager to implement this XEP, he/she should go
ahead and do so.

> The second reason I like the ideas of 0193/0225 is that this could really
> help for implementing clustering components.  I can see how a component
> could connect with two JIDs, one the component domain
> (component.domain.com), and a second would be a component-node-jid
> (component@domain.com/#####).  So that components could communicate with
> each other using their component-node-jid as a back-channel for coordination
> or what not, while still handling normal component traffic to their full
> domain.

Clustering components means you would need to cluster the server too, won't you?
I think this should be a different discussion and we should at least
think about not using XEPs for clustering.

> So I'm sorry, at the moment I'm not the one who can implement this ( i'm not
> a mina expert yet ).  But I wanted to get the idea out there before someone
> starts to implement external components. :)

Thanks for sharing these interesting throughts and pointers.
Currently, AFAIK, external components is not on our agenda - anyone?


View raw message