Hello. I'm looking over the code base and like I said before, I think
it looks great.
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. 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)
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...
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
([email protected]/#####). 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.
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. :)
http://xmpp.org/extensions/xep-0193.html
(incorporated into RFC 3920bis
http://tools.ietf.org/html/draft-saintandre-rfc3920bis
http://xmpp.org/extensions/xep-0225.html
<digression>Anyone located in SF/BayArea? Maybe people want to meet
face to face?</digression>
