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