> Itay Neeman wrote: >> Do people have any more thoughts on the matter? So far, the main points >> seems to be: >> >> 1. We need a way to link pubsub items to other pubsub items (whether PEP >> or vanilla PubSub). This can involve links to nodes on other pubsub >> services as well. > > What exactly do we mean by links? Do we mean things like "in-reply-to" > and "in-reference-to"? It seems to me that we're basically talking about > distributed threading of some kind. I assume the NNTP people solved this > problem back in 1987 or so. :) > >> 2. It is unclear what the best node topology for a blog is. > > I think this is more than blogs -- this is linking between any two given > pubsub nodes or items. Blogging is one application of that, but so might > be an NNTP-like netnews system. >
Well the simplistic view I have on this problem is that a resource (I purposefully don't use the term of blog here) could find a way, depending on its context, to advertise for the PubSub service associated with the resource itself. I guess in case a blog entry it could be along the lines of link[rel="pubsub-create"] to create a new node associated. Now if you go and use Atom to store metadata concerning the resource itself as per the XMPP-AtomPub ID then you could indeed use the in-reply-to element as per RFC 4685 to allow for item linking. That means of course that you must provide a valid IRI to each new item that is created. This does not solve really the linking of nodes but works well for all resources that have a IRI as long as you're ready to use an Atom entry to enclose that IRI. To me linking nodes would add layers of complexity upon PubSub and XMPP in general because it means you start inter-connecting somehow services that are not otherwise connected. Better using Atom to carry that bit of information and let consumers deal with it. After all what matters here is not the actual node but the resource linked from the item published to that node. - Sylvain
