[Social] R: blog integration

[Baldo Faieta]

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.
>