Blaine Cook wrote: > On Tue, Apr 15, 2008 at 11:56 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: >> 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...) > > i think that makes sense, though as a thought experiment, are there > any resources which are available via XMPP but are *not* available via > HTTP? My overall conception of XMPP is that it's a really fantastic > mechanism for real-time delivery of content, but probably not the > greatest mechanism for querying and representing data (if only because > HTTP is such a strongly established standard that everyone > understands).
There might be (even aside from jabber-specific things like my mood or avatar). One of the things I took away from the EComm conference and other recent discussions is that there are just applications. Some applications might have only HTTP interfaces. Some might have HTTP and XMPP interfaces. Some might have HTTP and phone interfaces (cf. examples from EComm). But some applications might have SMS + telephony interfaces or SMTP + XMPP interfaces or whatever. So I don't think it's absolutely necessary for an application to have an HTTP interface. For example we can store objects in an XMPP pubsub service without ever serving them via HTTP. Granted this is mostly useful for small, transient objects and we'd probably limit the history of such objects to 10 or 20 items, but that kind of usage might fit Atom quite well in certain scenarios. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
