I think it would be interesting for XMPP servers to support a mesh
configuration much like what you have in overlay P2P networks.
Effectively it comes down to supporting "dynamic federation" where the
servers, instead of being connected in a fixed topology, they would
join and leave to the mesh. Presumably, this can be done using
overlay mechanisms like Chord, pastry, etc. Where I see great value
is really in the massive scalability of this pubsub mesh. Basically,
a client can just connect to one of the servers in the mesh, and
pubsub notifications destined to the client will hop in between nodes
(servers) to get to it. The trick is that the nodes would be
configured following one of the overlay structures (say chord) and in
this way, the notifications would find their way. Using chord for
example, the nodes (servers) would just have log(n) connections to
deal with. From the server point of view, if it receives a
notification that it cannot handle, then it will pass it along one of
its nodes, which eventually either handle it or store it for later.
Anyway, the idea would be to support "dynamic federation" on the XMPP
protocol, that way, any server that supports it could be part of a
potentially very large mesh.
On 15 Apr 2008, at 19:12, Roberto Ostinelli wrote:
Agreed, I think.
My argument is that this doesn't matter, at least at this point.
I'm a big
fan
of use-case-driven development, and at the moment I'm not aware of a
single example
of, for example, two RSS / Atom feeds linking to each-other [as
metadata].
Linkages between PubSub Items is trivial and well understood, but
I'm not
even sure
what linkages between PubSub nodes would *mean*.
Web APIs work fine at the moment, and discovery is driven by
documentation, not high
engineering solutions.
b.
we do have an use case of the kind. it's a a distributed
architecture where
xmpp servers are the backbone.
instead of having an unique pubsub node on one unique centralized xmpp
server to which all interested entities subscribe (in a 1->n
relationship),
every xmpp that complies to the architecture has a pubsub node which
has a
standardized name, 'news', and every client which is interested
subscribes
to the 'news' pubsub node of its own xmpp server.
xmpp servers then provide relaying between 'news' node pubsubs, so
that an
item published on the 'news' pubsub node of xmpp server A is also
published
on the 'news' pubsub node of xmpp server B. this builds an n->n
relationship
and is interesting for many reasons.
i am not sure what is the best way to provide such relays, i'm
currently
using a xmpp server component which acts like a subscriber to the
'news'
pubsub node of other xmpp servers and:
- checks if a pubsub item has not been already treated [to avoid
redundancy];
- if not, publishes it on the 'news' pubsub node of its own xmpp
server.
just some thoughts.
r.
