Blaine Cook wrote: > On Tue, Apr 15, 2008 at 7:51 AM, Sylvain Hellegouarch <[EMAIL PROTECTED]> > wrote: >> 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. > > 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*.
Good point.
So I take it you see the linkage as happening within Atom? I suppose
that's good enough for now. Not everything published to a pubsub node
will be Atom, but for the use cases we're talking about linking within
Atom will work. Now we just need to figure out (if desired) the right
link structure for pointing to items as available on XMPP (not the
original HTTP URL, if any). So we could have an RFC 4685 in-reply-to
like this:
<thr:in-reply-to
ref="tag:example.org,2005:1"
type="application/xmpp+xml"
href="xmpp:example.org?;node=foo;item=bar"/>
(Not sure of the 'type' yet...)
> Web APIs work fine at the moment, and discovery is driven by
> documentation, not high engineering solutions.
:)
P
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
