Ralph (or anyone else), do you have feedback on this? /psa
On 05/14/2008 4:40 PM, Peter Saint-Andre wrote: > On 05/08/2008 3:36 AM, Ralph Meijer wrote: >> On Wed, 2008-05-07 at 11:32 -0600, Peter Saint-Andre wrote: >>> On 05/05/2008 2:07 PM, Peter Saint-Andre wrote: >>>> On 05/05/2008 8:34 AM, Bob Wyman wrote: >>>>> In case you haven't seen it, consider reading Michael Arrington's >>>>> TechCrunch >>>>> post calling for a decentralized Twitter. >>>>> (http://www.techcrunch.com/2008/05/05/twitter-can-be-liberated-heres-how/) >>>>> As noted by many of the commenters, and as should be obvious to anyone in >>>>> the Jabber community, the solution they are looking for is probably XMPP + >>>>> XEP-0060 + "Atom over XMPP". >>>> +1. Just had a chat with Joe Hildebrand about that. I'll start working >>>> on a spec about it tonight. Should be pretty straightforward. >>> http://www.xmpp.org/extensions/inbox/microblogging.html >> Good start, but I have a number of comments and questions to this >> proposal: >> >> For clarity, is the assumption that there is a microblogging service >> that exposes an XMPP interface in the form of JIDs for every user and >> PEP nodes tied to it, or that the server is a generic XMPP IM server >> with Personal Eventing capabilities? I am assuming the former. >> >> This spec limits its scope to microblogging. Why? It is kind of >> arbitrary whether a blog is micro, mini, macro or whatever. In the end >> it is usually just a blog, albeit with smaller pieces of text. Size and >> payload type (plain text vs. (x)html) are not enforced are they? Or >> would a publish request fail, depending on the service's configuration? >> I suppose that the <not-acceptable/> stanza error would be appropriate, >> but this is not referred to in XEP-0060 (Publish-Subscribe). >> >> Tied in to the previous item, because you use a fixed node id, you can >> only have one microblog tied to your account. I suppose that works for >> microblogging services, but this is pretty limiting for aggregating all >> your stuff at your own JID. >> >> The example of the usage of Entity Capabilities for automatic >> subscription to microblog updates is flawed in relation to how this is >> specified in XEP-0060. Section 10 there describes Filtered Notifications >> in combination with Automatic Subscription based on presence. The >> mechanics are as follows: >> >> Depending on the 'root' node's configuration, a contact that sends >> presence to a user with an account that has PEP support on its server, >> will be automatically subscribed to that 'root' node with a subscription >> type of 'items'. However, the items sent to you are filtered by using >> Entity Capabilities, if the service provides that feature. To tell the >> service what payloads to send, Service Discovery on the contact's >> resource that sent presence will yield Service Discovery features that >> are namespaces plus '+notify'. E.g. to get moods, you would advertise >> the feature 'http://jabber.org/protocol/mood+notify', and you would get >> all items that have a payload of which the root element is in the >> 'http://jabber.org/protocol/mood' namespace. >> >> This protoxep, however, shows that the payload is an Atom entry >> document, so the payload of the namespace is >> 'http://www.w3.org/2005/Atom'. Advertising 'urn:xmpp:tmp:microblog >> +notify' as a disco feature, thus should not yield any notifications. >> >> Please note that I think that this is not a broken design. Having the >> filtering mechanism as-is, allows for multiple nodes that send around >> data as Atom entry documents. If this protoxep is implemented as an >> interface to an existing microblogging service, you would probably want >> to get all Atom entries anyway. So advertising >> 'http://www.w3.org/2005/Atom+notify' would do the trick. Also note that >> this means that the node id itself is no longer relevant. A client could >> discover the user's nodes and use the node's meta data to detect the >> type of node and possibly allow the user to pick on, if there are >> multiple. I could imagine a meta data field that specifies the intended >> usage (blogging versus pictures versus yet another social object) next >> to the one for denoting the namespace of the payload. Note that the Atom >> Publishing protocol does something similar with Service Documents. > > I think we need to rethink this design a bit. > > In particular, I think it is useful to have two different filtering > mechanisms: > > 1. Filter on NodeID > > 2. Filter on payload namespace > > Why? Because this provides a way to receive only the particular > notifications you are interested in. > > Atom is a good example. Given that Atom is the new XML, everyone and > their uncle will provide an enormous range of information using Atom. > Not just blog feeds (what we traditionally think of as Atom) but, via > Atom extensions, potentially everything that we've defined as separate > payload namespaces for PEP (tune, mood, geolocation, and all the rest). > If I advertise http://www.w3.org/2005/Atom+notify then I will receive > everything that is published using Atom as a container. > > Now, that might be desirable sometimes. But sometimes I just want to > receive your blog feeds, or your microblog posts, or whatever. > > There are at least two possible approaches here (and perhaps others): > > 1. Wrap (some) Atom payloads in a wrapper element qualified by a special > namespace (one for microblogs, one for geoloc, etc.). > > 2. Define +notify as "match NodeID" and a new suffix (+filter?) as > "match payload namespace". > > This way, we can define urn:xmpp:microblog as a specialized usage of > Atom (and that's what it is, no?), and people who want to receive only > my microblogs (but not everything else that I might publish in the Atom > format) can do so. > > Thoughts? > > Peter
smime.p7s
Description: S/MIME Cryptographic Signature
