>> >> 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. > > > I don't think that the proper of seeing it. Nodes are discrete to the pubsub > service the live in. What matters is the item they carry, in turn that item is > actually just an envelop around a IRI that allows to retrieve the resource. The > distributed aspect is already existing thanks to that mechanism of URI/IRI. > > If you want several pubsub services to talk about the same resource simply ensure > each one has an item holding that IRI. > > I don't think propagating nodes is reasonable or has any benefit. > > - Sylvain
sorry about that, i should have mentioned that i wasn't talking about publishing content, instead, i'm interested in a 'social' version of pep, where events with a same 'scope' propagate in a distributed network architecture. the advantages are the ones of a distributed vs centralized arch. r.
