From jabber.list at gmail.com Tue Feb 3 12:24:49 2009 From: jabber.list at gmail.com (Adi) Date: Tue, 3 Feb 2009 10:24:49 -0800 Subject: [PubSub] Pubsub routing? Message-ID: <251409990902031024r407a52f0p9e6297c0c0862c47@mail.gmail.com> I had a few questions on XMPP routing. If i understand it correctly XMPP allows only routing of message packets and nothing else. Publish may still work as it uses messages to get the items to the destination. But you cannot rely on routing to subscribe to a node on another domain. When i subscribe to a node there is nothing in the packet that tells who the owner of the node is, so the current domain's database is checked to see if the node is available to be subscribed. -- Thanks, Adi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.jabber.org/pipermail/pubsub/attachments/20090203/0123eb58/attachment.htm From nathanfritz at gmail.com Tue Feb 3 12:33:45 2009 From: nathanfritz at gmail.com (Nathan Fritz) Date: Tue, 3 Feb 2009 10:33:45 -0800 Subject: [PubSub] Pubsub routing? In-Reply-To: <251409990902031024r407a52f0p9e6297c0c0862c47@mail.gmail.com> References: <251409990902031024r407a52f0p9e6297c0c0862c47@mail.gmail.com> Message-ID: I'm not sure what you mean by routing. All XMPP stanzas are routed to a domain name in the least, a user at domain/session-resource at the most. Subscribing to pubsub on another server is simply a matter of addressing said request to said server. As far as pep, the requests are sent to the users barejid (user at server), which for iq stanzas routs to the server in the user's name. There's no guesswork in this. -Nathan Fritz (cellphone) On Feb 3, 2009, at 10:24 AM, Adi wrote: > I had a few questions on XMPP routing. > > If i understand it correctly XMPP allows only routing of message > packets and nothing else. > > Publish may still work as it uses messages to get the items to the > destination. But you cannot rely on routing to subscribe to a node > on another domain. When i subscribe to a node there is nothing in > the packet that tells who the owner of the node is, so the current > domain's database is checked to see if the node is available to be > subscribed. > > -- > Thanks, > Adi From bcully at gmail.com Tue Feb 3 12:35:31 2009 From: bcully at gmail.com (Brian Cully) Date: Tue, 3 Feb 2009 13:35:31 -0500 Subject: [PubSub] Pubsub routing? In-Reply-To: <251409990902031024r407a52f0p9e6297c0c0862c47@mail.gmail.com> References: <251409990902031024r407a52f0p9e6297c0c0862c47@mail.gmail.com> Message-ID: <39F90290-DA98-47EA-90BA-2829F93E0546@gmail.com> On 3-Feb-2009, at 13:24, Adi wrote: > I had a few questions on XMPP routing. > > If i understand it correctly XMPP allows only routing of message > packets and nothing else. XMPP routes all stanzas according to the "to" attribute of the stanza element, not just messages. > Publish may still work as it uses messages to get the items to the > destination. But you cannot rely on routing to subscribe to a node > on another domain. When i subscribe to a node there is nothing in > the packet that tells who the owner of the node is, so the current > domain's database is checked to see if the node is available to be > subscribed. There should be no distinction from the client's point of view between subscribing to a local or remote node. In terms of server implementation, when a subscription request isn't local it should create a new s2s connection if necessary and forward the subscription request via s2s to the remote server. The remote server is the only one who's database should be checked, not the local. Ownership is a non-sequitur. The remote may or may not care about who owns the node, and it can always map that to your JID (as it's always present in both the stanza attributes and the "jid" attribute on the subscribe element.) -bjc From jabber.list at gmail.com Tue Feb 3 14:17:48 2009 From: jabber.list at gmail.com (Adi) Date: Tue, 3 Feb 2009 12:17:48 -0800 Subject: [PubSub] Pubsub routing? In-Reply-To: <39F90290-DA98-47EA-90BA-2829F93E0546@gmail.com> References: <251409990902031024r407a52f0p9e6297c0c0862c47@mail.gmail.com> <39F90290-DA98-47EA-90BA-2829F93E0546@gmail.com> Message-ID: <251409990902031217k7cd92c11r7d4bdf15a25c4ca2@mail.gmail.com> Got it. Thanks! On Tue, Feb 3, 2009 at 10:35 AM, Brian Cully wrote: > On 3-Feb-2009, at 13:24, Adi wrote: > > I had a few questions on XMPP routing. >> >> If i understand it correctly XMPP allows only routing of message packets >> and nothing else. >> > > XMPP routes all stanzas according to the "to" attribute of the > stanza element, not just messages. > > Publish may still work as it uses messages to get the items to the >> destination. But you cannot rely on routing to subscribe to a node on >> another domain. When i subscribe to a node there is nothing in the packet >> that tells who the owner of the node is, so the current domain's database is >> checked to see if the node is available to be subscribed. >> > > There should be no distinction from the client's point of view > between subscribing to a local or remote node. In terms of server > implementation, when a subscription request isn't local it should create a > new s2s connection if necessary and forward the subscription request via s2s > to the remote server. The remote server is the only one who's database > should be checked, not the local. > > Ownership is a non-sequitur. The remote may or may not care about > who owns the node, and it can always map that to your JID (as it's always > present in both the stanza attributes and the "jid" attribute on the > subscribe element.) > > -bjc > -- Thanks, Adi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.jabber.org/pipermail/pubsub/attachments/20090203/6b522379/attachment.htm From christophe.romain at process-one.net Wed Feb 4 10:25:32 2009 From: christophe.romain at process-one.net (Christophe Romain) Date: Wed, 4 Feb 2009 17:25:32 +0100 Subject: [PubSub] example 113 is wrong Message-ID: <20090204162532.GD3411@localhost> This has been said that when creating node, do not sending configure will act the same as sending empty configure. for not, the spec still stats that configure must be send into the create node stanza, that makes example 113 wrong. From bcully at gmail.com Fri Feb 6 21:57:50 2009 From: bcully at gmail.com (Brian Cully) Date: Fri, 6 Feb 2009 22:57:50 -0500 Subject: [PubSub] example 113 is wrong In-Reply-To: <20090204162532.GD3411@localhost> References: <20090204162532.GD3411@localhost> Message-ID: <9992033D-026B-4DF5-82D3-36B7ED6BAFCB@gmail.com> Personally, I feel that for ease-of-use node creation should not require configuration. There are two reasons for this: 1) easy things should be easy, and 2) supplying an empty config element, which is acceptable, should be semantically equivalent to supplying no config element, which is the same as taking the default config. The reason for the former should be self-explanatory, and the reason for the latter is that in both cases (supplying empty config vs. no config) there is no change in the amount of information, just in boilerplate. -bjc On Feb 4, 2009, at 11:25, Christophe Romain wrote: > This has been said that when creating node, do not sending configure > will act the same as sending empty configure. > for not, the spec still stats that configure must be send into the > create node stanza, that makes example 113 wrong. > From stpeter at stpeter.im Tue Feb 10 21:22:53 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 11 Feb 2009 04:22:53 +0100 Subject: [PubSub] Brussels report Message-ID: <4992448D.30705@stpeter.im> At the XMPP Summit yesterday, we talked a bit about PubSub and PEP. I didn't participate in this small group discussion the whole time because I was moving from group to group, so hopefully people can correct me where my information is wrong or incomplete. However, I think we came to the following conclusions: 1. The "one node per namespace" rule in PEP is overly restrictive. The canonical example of why we need to remove this restriction is Atom (it can be used for blog posts, GeoRSS, and a dozen other things). To relax this restriction, we would define well-known NodeIDs and specify that the node's payload type is Atom or whatever. Existing PEP payload specs (tunes, mood, etc.) might be updated to specify that there might be compatibility problems if you attempt to publish that payload to a NodeID that does not match the namespace (however, I don't think even this is necessary because nothing will break if new NodeIDs are mapped to existing payload types). 2. Nathan Fritz explained that Seesmic sets the pubsub#expire field to "presence" in order to indicate that a subscription will run out when the service receives unavailable presence from the subscriber (in their system, I think this is typically a full JID). We had consensus that this is fine and that we don't need a new subscription option for such temporary subscriptions. 3. We discussed presence-based delivery. I think the conclusion was that the service could generate one notification for each resource in this case, rather than sending one notification to the bare JID of the subscriber and depending on the receiving server to send it to one or more resource. 4. The subscription depth stuff for collection nodes is madness and needs to be removed from the spec. 5. Ralph Meijer and Blaine Cook argued that we may not need collections at all, but I missed that part of the discussion. 6. In general the spec needs a cleanup and perhaps another round of simplification or pruning. This is on my priority list, but I think it might be slightly lower than the Jingle modifications (see discussion on the Jingle list). Anything else? /psa [ written en route from Brussels, delivery times may vary :) ] -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/pubsub/attachments/20090211/7343f686/attachment.bin From dmeyer at tzi.de Wed Feb 11 06:39:43 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Wed, 11 Feb 2009 13:39:43 +0100 Subject: [PubSub] Brussels report In-Reply-To: <4992448D.30705@stpeter.im> (Peter Saint-Andre's message of "Wed\, 11 Feb 2009 04\:22\:53 +0100") References: <4992448D.30705@stpeter.im> Message-ID: <87y6wd87w0.fsf@phex.sachmittel.de> Peter Saint-Andre wrote: > At the XMPP Summit yesterday, we talked a bit about PubSub and PEP. I > didn't participate in this small group discussion the whole time because > I was moving from group to group, so hopefully people can correct me > where my information is wrong or incomplete. However, I think we came to > the following conclusions: [...] > Anything else? My notes say something about "PEP will only have one item in each node. Only used for eventing and not to store stuff". IMHO we need to discuss this. Right now XEP-0189 requires PEP with several items. Dirk -- Life is complex, it has a real part and an imaginary part. From stpeter at stpeter.im Wed Feb 11 06:59:22 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 11 Feb 2009 05:59:22 -0700 Subject: [PubSub] Brussels report In-Reply-To: <87y6wd87w0.fsf@phex.sachmittel.de> References: <4992448D.30705@stpeter.im> <87y6wd87w0.fsf@phex.sachmittel.de> Message-ID: <4992CBAA.60808@stpeter.im> Dirk Meyer wrote: > Peter Saint-Andre wrote: >> At the XMPP Summit yesterday, we talked a bit about PubSub and PEP. I >> didn't participate in this small group discussion the whole time because >> I was moving from group to group, so hopefully people can correct me >> where my information is wrong or incomplete. However, I think we came to >> the following conclusions: > [...] >> Anything else? > > My notes say something about "PEP will only have one item in each > node. Only used for eventing and not to store stuff". IMHO we need to > discuss this. Right now XEP-0189 requires PEP with several items. I wasn't in the pubsub group when they discussed that, so I'm not sure about the reasoning. Perhaps someone could elaborate? /psa -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/pubsub/attachments/20090211/d6099630/attachment.bin From ralphm at ik.nu Wed Feb 11 07:50:28 2009 From: ralphm at ik.nu (Ralph Meijer) Date: Wed, 11 Feb 2009 14:50:28 +0100 Subject: [PubSub] Brussels report In-Reply-To: <4992CBAA.60808@stpeter.im> References: <4992448D.30705@stpeter.im> <87y6wd87w0.fsf@phex.sachmittel.de> <4992CBAA.60808@stpeter.im> Message-ID: <4992D7A4.7040609@ik.nu> On 2009-02-11 13:59, Peter Saint-Andre wrote: > Dirk Meyer wrote: >> Peter Saint-Andre wrote: >>> At the XMPP Summit yesterday, we talked a bit about PubSub and PEP. I >>> didn't participate in this small group discussion the whole time because >>> I was moving from group to group, so hopefully people can correct me >>> where my information is wrong or incomplete. However, I think we came to >>> the following conclusions: >> [...] >>> Anything else? >> My notes say something about "PEP will only have one item in each >> node. Only used for eventing and not to store stuff". IMHO we need to >> discuss this. Right now XEP-0189 requires PEP with several items. > > I wasn't in the pubsub group when they discussed that, so I'm not sure > about the reasoning. Perhaps someone could elaborate? The reasoning went like the following. PEP was created specifically to make an easy-to-use and easy-to-implement subset of Publish-Subscribe (XEP-0060). During the lengthy debates that eventually yielded XEP-0163 as we know it, the emphasis was very explicitly on a minimal feature set and smart defaults. To me, PEP is for the use cases that follow the principles as written in XEP-0163's section 2. The requirement of one item per node has always been there implicitly in my recollection, and makes perfects sense for publishing extended presence. No history required. Public Key Publishing (XEP-0189) does in fact mention PEP but relies on Best Practices for Persistent Storage of Public Data via Publish-Subscribe (XEP-0222), which is really another profile on XEP-0060 that also uses the concept of nodes tied to user accounts. And that brings me to why we had this discussion in the first place: new use cases. More and more social networking services (and beyond) feel the need to make use of XMPP publish-subscribe technologies to provide access to their service. Common requirements seem to include: * Common exchange format (Atom) for different types of social objects * History * Fine(r) grained access control Nevertheless, the concept of providing nodes linked to user accounts, where the those user accounts have their own jid of the form user at service, still has great appeal. The general consensus seemed to be that we should keep PEP for the limited use cases, while expanding server side implementations with more features from XEP-0060. I'd really like a good short name/acronym for nodes on a user account, by the way. It seems that a lot of confusion is there because some people refer to just that feature as PEP. ralphm From kevin at kismith.co.uk Wed Feb 11 07:54:47 2009 From: kevin at kismith.co.uk (Kevin Smith) Date: Wed, 11 Feb 2009 13:54:47 +0000 Subject: [PubSub] Brussels report In-Reply-To: <4992D7A4.7040609@ik.nu> References: <4992448D.30705@stpeter.im> <87y6wd87w0.fsf@phex.sachmittel.de> <4992CBAA.60808@stpeter.im> <4992D7A4.7040609@ik.nu> Message-ID: On Wed, Feb 11, 2009 at 1:50 PM, Ralph Meijer wrote: > The general consensus seemed to be that we should keep PEP for the limited > use cases, while expanding server side implementations with more features > from XEP-0060. Without having been party to the discussion this time, this has been the conclusion we've reached in the past in other discussions. > I'd really like a good short name/acronym for nodes on a user account, by > the way. It seems that a lot of confusion is there because some people refer > to just that feature as PEP. PUP? (the People's Ultimate PubSub). /K From dmeyer at tzi.de Wed Feb 11 08:21:00 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Wed, 11 Feb 2009 15:21:00 +0100 Subject: [PubSub] Brussels report In-Reply-To: <4992D7A4.7040609@ik.nu> (Ralph Meijer's message of "Wed\, 11 Feb 2009 14\:50\:28 +0100") References: <4992448D.30705@stpeter.im> <87y6wd87w0.fsf@phex.sachmittel.de> <4992CBAA.60808@stpeter.im> <4992D7A4.7040609@ik.nu> Message-ID: <87skml8377.fsf@phex.sachmittel.de> Ralph Meijer wrote: > Nevertheless, the concept of providing nodes linked to user accounts, > where the those user accounts have their own jid of the form > user at service, still has great appeal. > > The general consensus seemed to be that we should keep PEP for the > limited use cases, while expanding server side implementations with > more features from XEP-0060. > > I'd really like a good short name/acronym for nodes on a user account, > by the way. It seems that a lot of confusion is there because some > people refer to just that feature as PEP. Right. I prefer PEP over "raw" PubSub because I do not have to search for a PubSub server and do not need to figure out where I can store stuff. E.g. ejabberd uses pubsub.server.tld and the (default) root node for a user is home/server.tld/username. How can a client know that? IMHO a server should provide a user PubSub tree with standardized names. I want to know where a PubSub tree is a can write my keys to and I also want to know where the PubSub nodes for my friend's are. Dirk -- Take care to get what you like, otherwise you will be forced to like what you get. From kevin at kismith.co.uk Wed Feb 11 08:32:15 2009 From: kevin at kismith.co.uk (Kevin Smith) Date: Wed, 11 Feb 2009 14:32:15 +0000 Subject: [PubSub] Brussels report In-Reply-To: <87skml8377.fsf@phex.sachmittel.de> References: <4992448D.30705@stpeter.im> <87y6wd87w0.fsf@phex.sachmittel.de> <4992CBAA.60808@stpeter.im> <4992D7A4.7040609@ik.nu> <87skml8377.fsf@phex.sachmittel.de> Message-ID: On Wed, Feb 11, 2009 at 2:21 PM, Dirk Meyer wrote: > Right. I prefer PEP over "raw" PubSub because I do not have to search > for a PubSub server and do not need to figure out where I can store > stuff. E.g. ejabberd uses pubsub.server.tld and the (default) root node > for a user is home/server.tld/username. How can a client know that? > > IMHO a server should provide a user PubSub tree with standardized > names. I want to know where a PubSub tree is a can write my keys to and > I also want to know where the PubSub nodes for my friend's are. The pubsub-on-a-jid stuff is in -0060 now, not just -0163 (Which is now only a profile), so you don't need to use PEP, just because you want stuff to live in a sensible place. /K From oej at edvina.net Wed Feb 11 08:40:46 2009 From: oej at edvina.net (Johansson Olle E) Date: Wed, 11 Feb 2009 15:40:46 +0100 Subject: [PubSub] Brussels report In-Reply-To: <87skml8377.fsf@phex.sachmittel.de> References: <4992448D.30705@stpeter.im> <87y6wd87w0.fsf@phex.sachmittel.de> <4992CBAA.60808@stpeter.im> <4992D7A4.7040609@ik.nu> <87skml8377.fsf@phex.sachmittel.de> Message-ID: 11 feb 2009 kl. 15.21 skrev Dirk Meyer: > Ralph Meijer wrote: >> Nevertheless, the concept of providing nodes linked to user accounts, >> where the those user accounts have their own jid of the form >> user at service, still has great appeal. >> >> The general consensus seemed to be that we should keep PEP for the >> limited use cases, while expanding server side implementations with >> more features from XEP-0060. >> >> I'd really like a good short name/acronym for nodes on a user >> account, >> by the way. It seems that a lot of confusion is there because some >> people refer to just that feature as PEP. > > Right. I prefer PEP over "raw" PubSub because I do not have to search > for a PubSub server and do not need to figure out where I can store > stuff. E.g. ejabberd uses pubsub.server.tld and the (default) root > node > for a user is home/server.tld/username. How can a client know that? Is there a way to redirect from this "well known address" to a server-specific address, like a component? > > IMHO a server should provide a user PubSub tree with standardized > names. I want to know where a PubSub tree is a can write my keys to > and > I also want to know where the PubSub nodes for my friend's are. > It has to be optional though. There are reasons why I don't want to do that. /O From bcully at gmail.com Wed Feb 11 08:58:56 2009 From: bcully at gmail.com (Brian Cully) Date: Wed, 11 Feb 2009 09:58:56 -0500 Subject: [PubSub] Brussels report In-Reply-To: <4992448D.30705@stpeter.im> References: <4992448D.30705@stpeter.im> Message-ID: <094A847C-2C6A-4988-ADC8-61F7D6E2E812@gmail.com> On 10-Feb-2009, at 22:22, Peter Saint-Andre wrote: > 1. The "one node per namespace" rule in PEP is overly restrictive. The > canonical example of why we need to remove this restriction is Atom > (it > can be used for blog posts, GeoRSS, and a dozen other things). To > relax > this restriction, we would define well-known NodeIDs and specify that > the node's payload type is Atom or whatever. Existing PEP payload > specs > (tunes, mood, etc.) might be updated to specify that there might be > compatibility problems if you attempt to publish that payload to a > NodeID that does not match the namespace (however, I don't think even > this is necessary because nothing will break if new NodeIDs are mapped > to existing payload types). I assume this means adding a node config option "mime_type" or something similar? If so, I think this is a pretty good idea and it simplifies things on the client end a great deal in some cases. > 4. The subscription depth stuff for collection nodes is madness and > needs to be removed from the spec. I disagree. Subscription depth makes for very simple client implementations for apps built heavily on PubSub. What's the objection here? Also, if you get rid of subscription depth, you also need to kill subscription type (items vs. nodes), as w/o depth it becomes useless. Unless I'm missing something fundamental, subscription depth strikes me as a pretty good idea. > 5. Ralph Meijer and Blaine Cook argued that we may not need > collections > at all, but I missed that part of the discussion. Someone needs to explain this to me, too. I'm having a hard time figuring out why a flat node space is somehow better than the options provided for by collections. -bjc From dmeyer at tzi.de Wed Feb 11 09:00:06 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Wed, 11 Feb 2009 16:00:06 +0100 Subject: [PubSub] Brussels report In-Reply-To: (Kevin Smith's message of "Wed\, 11 Feb 2009 14\:32\:15 +0000") References: <4992448D.30705@stpeter.im> <87y6wd87w0.fsf@phex.sachmittel.de> <4992CBAA.60808@stpeter.im> <4992D7A4.7040609@ik.nu> <87skml8377.fsf@phex.sachmittel.de> Message-ID: <87myct81e1.fsf@phex.sachmittel.de> Kevin Smith wrote: > On Wed, Feb 11, 2009 at 2:21 PM, Dirk Meyer wrote: >> Right. I prefer PEP over "raw" PubSub because I do not have to search >> for a PubSub server and do not need to figure out where I can store >> stuff. E.g. ejabberd uses pubsub.server.tld and the (default) root node >> for a user is home/server.tld/username. How can a client know that? >> >> IMHO a server should provide a user PubSub tree with standardized >> names. I want to know where a PubSub tree is a can write my keys to and >> I also want to know where the PubSub nodes for my friend's are. > > The pubsub-on-a-jid stuff is in -0060 now, not just -0163 (Which is > now only a profile), so you don't need to use PEP, just because you > want stuff to live in a sensible place. It is such a huge doc, I can't find it. Can you provide me a pointer to the section in question? Dirk -- Save time... see it my way. From dave at cridland.net Wed Feb 11 09:00:17 2009 From: dave at cridland.net (Dave Cridland) Date: Wed, 11 Feb 2009 15:00:17 +0000 Subject: [PubSub] Brussels report In-Reply-To: References: <4992448D.30705@stpeter.im> <87y6wd87w0.fsf@phex.sachmittel.de> <4992CBAA.60808@stpeter.im> <4992D7A4.7040609@ik.nu> Message-ID: <23846.1234364417.065441@peirce.dave.cridland.net> On Wed Feb 11 13:54:47 2009, Kevin Smith wrote: > On Wed, Feb 11, 2009 at 1:50 PM, Ralph Meijer wrote: > > The general consensus seemed to be that we should keep PEP for > the limited > > use cases, while expanding server side implementations with more > features > > from XEP-0060. > > Without having been party to the discussion this time, this has been > the conclusion we've reached in the past in other discussions. > > Right, so a PubSub service hanging off a person's jid is >= PEP, not *just* PEP. I think XEP-0163 might do well to mention this, perhaps. > > I'd really like a good short name/acronym for nodes on a user > account, by > > the way. It seems that a lot of confusion is there because some > people refer > > to just that feature as PEP. > > PUP? (the People's Ultimate PubSub). PAP - Personally Associated Pubsub. Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From ralphm at ik.nu Wed Feb 11 09:02:26 2009 From: ralphm at ik.nu (Ralph Meijer) Date: Wed, 11 Feb 2009 16:02:26 +0100 Subject: [PubSub] Brussels report In-Reply-To: <87skml8377.fsf@phex.sachmittel.de> References: <4992448D.30705@stpeter.im> <87y6wd87w0.fsf@phex.sachmittel.de> <4992CBAA.60808@stpeter.im> <4992D7A4.7040609@ik.nu> <87skml8377.fsf@phex.sachmittel.de> Message-ID: <4992E882.5090308@ik.nu> On 2009-02-11 15:21, Dirk Meyer wrote: > Ralph Meijer wrote: >> Nevertheless, the concept of providing nodes linked to user accounts, >> where the those user accounts have their own jid of the form >> user at service, still has great appeal. >> >> The general consensus seemed to be that we should keep PEP for the >> limited use cases, while expanding server side implementations with >> more features from XEP-0060. >> >> I'd really like a good short name/acronym for nodes on a user account, >> by the way. It seems that a lot of confusion is there because some >> people refer to just that feature as PEP. > > Right. I prefer PEP over "raw" PubSub because I do not have to search > for a PubSub server and do not need to figure out where I can store > stuff. You've just proven my point. One of the features of PEP is that nodes are tied to user accounts (xmpp:ralphm at example.org?;node=mynode) instead of a generic publish-subscribe service that has its own JID (xmpp:pubsub.example.org?;node=ralphm_node). Having nodes associated with a JID explicitly, makes discovery easier for subscribers. For publishers, the advantage is that you can use well-known node identifiers that are identical for each user. You still have to discover that your server supports PEP. In the same manner it could discover where your server's pubsub service is, although this requires more queries. That said, nodes tied to a user account are not a feature unique to PEP, but are defined in section 9 of XEP-0060. Maybe we need to define a discovery feature to make this feature explicitly discoverable. > E.g. ejabberd uses pubsub.server.tld and the (default) root node > for a user is home/server.tld/username. How can a client know that? I want to make one point here about ejabberd's organisation of nodes, although I don't know if recent versions still do this. In my opinion, making node identifiers non-opaque in this way for a generic publish subscribe service is confusing, limiting and sets a bad example. Limiting because particular use cases, like transferring ownership of a node, are impossible. I would even go as far as rating it broken. > IMHO a server should provide a user PubSub tree with standardized > names. I want to know where a PubSub tree is a can write my keys to > and I also want to know where the PubSub nodes for my friend's are. Assuming nodes-tied-to-a-user-account is available, you still need some way to know about the node names. This could be through discovery or a search (XEP-0055 with data forms). However, well-known names seem to have a strong preference. In this case, as you add support for a particular feature in your client (e.g. User Tune), the node identifier is known because it is defined by the specification. Stated differently: you cannot implement publish-subscribe generically in a client. You always implement a particular use of publish-subscribe, with its associated payload format(s), well-known node identifier(s) or a way to discover them, etc. As for subscribing to nodes, PEP uses the automatic subscription and namespace filtering features via Entity Capabilities (XEP-0115) from XEP-0060 to make this easier. Unfortunately this uncovers the following issue: Recently, the text in section 9.2 (Filtered Notifications) was updated to clarify how this feature works exactly, with this in a nice box: Note: In the context of personal eventing, the +notify feature means that the subscriber will receive notifications only from the node whose NodeID matches the desired namespace, because there is one node per namespace and one namespace per node. Upon rethinking that phrase, it means that +notify breaks as soon as a service implements more than just PEP and allows for more than one node that publishes in a particular namespace (e.g. a Buddycloud-like service that publishes to also publishes to a node that keeps a location history). Unsuspecting PEP-only clients will suddenly receive notifications from other nodes. ralphm From stpeter at stpeter.im Wed Feb 11 09:32:56 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 11 Feb 2009 08:32:56 -0700 Subject: [PubSub] PEP PIP PAP PUP -- POP! Message-ID: <4992EFA8.405@stpeter.im> I hate to pop your bubble, but I would suggest that we not get too hung up on marketing, which is all that the "Eventing" in PEP really is. (Backstory: I had a chat with Rohit Khare of KnowNow some years ago at a conference and he said it was a shame that the idea of publish-subscribe technologies hadn't taken off because they are so useful but needed a catchy name; I suggested "eventing" and then applied that to XEP-0163.) I don't think the "Eventing" in PEP means that every PEP node needs to be a singleton node (one item only), or that PEP can be used only for "personal" payload types. In fact I don't know if PEP really exists as a separate service. It's all just PubSub with various feature sets applied. If a given implementation of pubsub-on-a-jid (your bare JID is a virtual pubsub service) stores more than one item or even returns more than just the last published item on subscribe, what's the harm? Perhaps it would help to think about these feature sets at a more granular level and apply them to various payload types or well-known NodeIDs. For example, for tunes publishing (XEP-0118) we might recommend that the NodeID shall be "http://jabber.org/protocol/tune", that the node shall send a notification on presence and on subscription but only send the last item, that we use the +notify caps extension to signal interest and establish temporary/implicit subscriptions, etc. However, for public key publishing (XEP-0189) we might recommend a slightly different set of configuration options. I suppose the problem here is that the pubsub server would then need to know something about these well-known nodes instead of being completely generic. However, that seems consistent with the "simple clients, complex servers" philosophy that we tout so often, and it would apply only to well-known nodes. Thoughts? /psa -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/pubsub/attachments/20090211/e0b91d7d/attachment-0001.bin From ralphm at ik.nu Wed Feb 11 09:41:37 2009 From: ralphm at ik.nu (Ralph Meijer) Date: Wed, 11 Feb 2009 16:41:37 +0100 Subject: [PubSub] Brussels report In-Reply-To: <094A847C-2C6A-4988-ADC8-61F7D6E2E812@gmail.com> References: <4992448D.30705@stpeter.im> <094A847C-2C6A-4988-ADC8-61F7D6E2E812@gmail.com> Message-ID: <4992F1B1.7080403@ik.nu> On 2009-02-11 15:58, Brian Cully wrote: > On 10-Feb-2009, at 22:22, Peter Saint-Andre wrote: > >> 1. The "one node per namespace" rule in PEP is overly restrictive. The >> canonical example of why we need to remove this restriction is Atom (it >> can be used for blog posts, GeoRSS, and a dozen other things). To relax >> this restriction, we would define well-known NodeIDs and specify that >> the node's payload type is Atom or whatever. Existing PEP payload specs >> (tunes, mood, etc.) might be updated to specify that there might be >> compatibility problems if you attempt to publish that payload to a >> NodeID that does not match the namespace (however, I don't think even >> this is necessary because nothing will break if new NodeIDs are mapped >> to existing payload types). > > I assume this means adding a node config option "mime_type" or > something similar? If so, I think this is a pretty good idea and it > simplifies things on the client end a great deal in some cases. The pubsub#type node configuration/meta-data field is defined for this purpose. The proposal is to have specifications that register a node identifier (e.g. urn:xmpp:blog:0), to which Atom entry document representations of a blog posting can be published to. Another specification instead might define how you can find all nodes that use a particular payload format using Jabber Search (XEP-0055) with Data Forms, without using well-known names. Yet another possibility is that node-identifiers are discovered out-of-band, e.g. via HTTP link headers, HTML link elements or Atom link elements. >> 4. The subscription depth stuff for collection nodes is madness and >> needs to be removed from the spec. > > I disagree. Subscription depth makes for very simple client > implementations for apps built heavily on PubSub. What's the objection > here? Also, if you get rid of subscription depth, you also need to kill > subscription type (items vs. nodes), as w/o depth it becomes useless. > > Unless I'm missing something fundamental, subscription depth strikes > me as a pretty good idea. Well, I'd like to see some solid use cases for having subscriptions depths of 'all'. The default is '1' and if you only implement that, the multi-graph is very shallow and way easier to implement on the server side. I agree you can't do away with both if you still want to be able subscribe with a subscription type of 'items'. That said, maybe only getting updates on new nodes or just for discoverability, collections could still be useful. >> 5. Ralph Meijer and Blaine Cook argued that we may not need collections >> at all, but I missed that part of the discussion. > > Someone needs to explain this to me, too. I'm having a hard time > figuring out why a flat node space is somehow better than the options > provided for by collections. The usefulness of collections was questioned by me, in the context of social network federation. In a generic publish subscribe service you create leaf and collection nodes to provide certain feeds to subscribe to. Items are explicitly published to one node (only) and notifications will always mention this node identifier, even if you subscribed through a collection. However, if XMPP publish-subscribe is 'just' another interface to your service, your implementation typically only uses the subscription and notification parts of the publish-subscribe protocol. I.e. you don't actually use the publishing protocol, but instead publishing magically happens internal to your service. In that case, nodes are an abstraction of your backend and a particular item just happens to yield notifications on multiple (leaf) nodes, without having a 'home' node. We coined this node-as-code. Note that the above doesn't affect the use case of having 3rd party client applications that use the publishing part of publish-subscribe to bring new items into the system. Even though it might seem that a particular item is 'home' to a particular node, the domain model for a service might not have such an explicit organization of nodes. Collections likely have other use-cases, though. I don't have a solid reason to do away with them, yet. ralphm From ralphm at ik.nu Wed Feb 11 10:11:14 2009 From: ralphm at ik.nu (Ralph Meijer) Date: Wed, 11 Feb 2009 17:11:14 +0100 Subject: [PubSub] PEP PIP PAP PUP -- POP! In-Reply-To: <4992EFA8.405@stpeter.im> References: <4992EFA8.405@stpeter.im> Message-ID: <4992F8A2.2050602@ik.nu> On 2009-02-11 16:32, Peter Saint-Andre wrote: > I hate to pop your bubble, but I would suggest that we not get too hung > up on marketing, which is all that the "Eventing" in PEP really is. > > (Backstory: I had a chat with Rohit Khare of KnowNow some years ago at a > conference and he said it was a shame that the idea of publish-subscribe > technologies hadn't taken off because they are so useful but needed a > catchy name; I suggested "eventing" and then applied that to XEP-0163.) > > I don't think the "Eventing" in PEP means that every PEP node needs to > be a singleton node (one item only), or that PEP can be used only for > "personal" payload types. In fact I don't know if PEP really exists as a > separate service. It's all just PubSub with various feature sets > applied. If a given implementation of pubsub-on-a-jid (your bare JID is > a virtual pubsub service) stores more than one item or even returns more > than just the last published item on subscribe, what's the harm? I agree that there's more to "eventing" or node-tied-to-a-user-account than what is currently defined in XEP-0163. However the terminology and surrounding discussion is unclear, imprecise and often even plainly wrong. The only 'harm' I can see from a technical perspective is the '+notify' feature, as I mentioned in another message: http://mail.jabber.org/pipermail/pubsub/2009-February/000097.html The only solution I can think of, is to redefine +notify to restrict on node identifier, not on payload namespace. This probably coincides with real-world use. I'd like to hear from implementors that followed the specification to the letter. If the currently specified behavior of filtering on payload namespace is still desired, we can think up a new suffix. > Perhaps it would help to think about these feature sets at a more > granular level and apply them to various payload types or well-known > NodeIDs. > > For example, for tunes publishing (XEP-0118) we might recommend that the > NodeID shall be "http://jabber.org/protocol/tune", that the node shall > send a notification on presence and on subscription but only send the > last item, that we use the +notify caps extension to signal interest and > establish temporary/implicit subscriptions, etc. One of the problems with the 'User *' specifications is that they both define the payload format as well as one particular use of them. This clouds other use cases. > However, for public key publishing (XEP-0189) we might recommend a > slightly different set of configuration options. > > I suppose the problem here is that the pubsub server would then need to > know something about these well-known nodes instead of being completely > generic. However, that seems consistent with the "simple clients, > complex servers" philosophy that we tout so often, and it would apply > only to well-known nodes. I think the problem is indeed in what the default node configuration is. However, for example, XEP-0189 explicitly uses node configuration. You could make the default node configuration for all nodes have the 'smart defaults' that XEP-0163 dictates. For all other profiles that want to deviate from those, you then require that they create nodes explicitly with a node configuration and/or use the publish-options functionality. This at least is backwards compatible with PEP as currently defined. For now I'm not in favor of making pubsub services 'smarter'. ralphm From kevin at kismith.co.uk Wed Feb 11 10:26:32 2009 From: kevin at kismith.co.uk (Kevin Smith) Date: Wed, 11 Feb 2009 16:26:32 +0000 Subject: [PubSub] PEP PIP PAP PUP -- POP! In-Reply-To: <4992F8A2.2050602@ik.nu> References: <4992EFA8.405@stpeter.im> <4992F8A2.2050602@ik.nu> Message-ID: On Wed, Feb 11, 2009 at 4:11 PM, Ralph Meijer wrote: > I think the problem is indeed in what the default node configuration is. > However, for example, XEP-0189 explicitly uses node configuration. You > could make the default node configuration for all nodes have the 'smart > defaults' that XEP-0163 dictates. For all other profiles that want to > deviate from those, you then require that they create nodes explicitly with > a node configuration and/or use the publish-options functionality. > This at least is backwards compatible with PEP as currently defined. For now I'm happy with 163 defaults being the smart defaults for all pubsub, and anything else can use node configuration - that seems fine to me. >> I suppose the problem here is that the pubsub server would then need to >> know something about these well-known nodes instead of being completely >> generic. However, that seems consistent with the "simple clients, >> complex servers" philosophy that we tout so often, and it would apply >> only to well-known nodes. > I'm not in favor of making pubsub services 'smarter'. I'm a lazy client dev who doesn't care about how hard server devs' lives are, and even I don't see much value in requiring servers to know about the payloads ;) /K From bcully at gmail.com Wed Feb 11 11:00:13 2009 From: bcully at gmail.com (Brian Cully) Date: Wed, 11 Feb 2009 12:00:13 -0500 Subject: [PubSub] Brussels report In-Reply-To: <4992F1B1.7080403@ik.nu> References: <4992448D.30705@stpeter.im> <094A847C-2C6A-4988-ADC8-61F7D6E2E812@gmail.com> <4992F1B1.7080403@ik.nu> Message-ID: <5D46CD43-EC11-49F4-B4B0-0DC8523272D6@gmail.com> On 11-Feb-2009, at 10:41, Ralph Meijer wrote: > The pubsub#type node configuration/meta-data field is defined for > this purpose. The proposal is to have specifications that register a > node identifier (e.g. urn:xmpp:blog:0), to which Atom entry document > representations of a blog posting can be published to. Another > specification instead might define how you can find all nodes that > use a particular payload format using Jabber Search (XEP-0055) with > Data Forms, without using well-known names. Yet another possibility > is that node-identifiers are discovered out-of-band, e.g. via HTTP > link headers, HTML link elements or Atom link elements. I really don't want there to be "special" NodeIDs; IOW, semantics being mappable from NodeID directly. Down this path lay madness. What happens when you need to internationalize, for instance? Who maintains the registrar? How do I use my own names w/o registering? Don't I have to deal with enough of this already? IMHO, out-of-band discovery makes the most sense (it's worked pretty well for the web so far, though, admittedly, XMPP doesn't have the same robust content-type negotiation). > Well, I'd like to see some solid use cases for having subscriptions > depths of 'all'. The default is '1' and if you only implement that, > the multi-graph is very shallow and way easier to implement on the > server side. Depends on what you mean by "solid." I chose to implement it so my clients would have a dead-simple API that was still flexible; we have a node tree set up to allow you to subscribe for events at various aggregation levels, depending on needs. That's nice and all, but what most people are going to want to do is see everything they can. With depth of "all" and type "items", you get that in one sub and no other work. I think that's really sweet. So sweet, I even implemented it for ejabberd (see the "bjc/master" branch of http://github.com/bjc/ejabberd), and the hard part there was supporting depth "1" - the rest just fell out of the design. I'm pretty sure OpenFire also implements sub depth and type, but I can't go check right now. For the record, we chose DAG-style collections because of the requirements of our service. We're publishing quite a lot of data which every user gets a slightly different aggregation of. Doing a one- to-one or one-to-many design would have resulted in a data explosion. By using collection nodes in many-to-many fashion, we can keep one item on the backend which publishes only to those who are supposed to see it by virtue of the collection hierarchy. But, again, mostly our users are going to want to see everything they can see, in other words, subscribe to root, type "items," depth "all." > I agree you can't do away with both if you still want to be able > subscribe with a subscription type of 'items'. That said, maybe > only getting updates on new nodes or just for discoverability, > collections could still be useful. You could do it either way. Personally, I like to keep the complexity here in the server. It just seems like this is forcing complexity on the client to save the time of server implementors. There's a time and a place for that, but I don't think this is it. > The usefulness of collections was questioned by me, in the context > of social network federation. > > In a generic publish subscribe service you create leaf and > collection nodes to provide certain feeds to subscribe to. Items are > explicitly published to one node (only) and notifications will > always mention this node identifier, even if you subscribed through > a collection. > > However, if XMPP publish-subscribe is 'just' another interface to > your service, your implementation typically only uses the > subscription and notification parts of the publish-subscribe > protocol. I.e. you don't actually use the publishing protocol, but > instead publishing magically happens internal to your service. I'm missing something here. How is using publish and subscribe not using the publishing protocol? Does it make a difference if I retract items, too? To abuse Roy Fielding, I'm "using PubSub as the engine of application state." I wonder how that differs from what you mean by "[using] the publishing protocol." > In that case, nodes are an abstraction of your backend and a > particular item just happens to yield notifications on multiple > (leaf) nodes, without having a 'home' node. We coined this node-as- > code. Can you give a more concrete example? This sounds vaguely like something I might want, but I can't figure what you mean. > Note that the above doesn't affect the use case of having 3rd party > client applications that use the publishing part of publish- > subscribe to bring new items into the system. Even though it might > seem that a particular item is 'home' to a particular node, the > domain model for a service might not have such an explicit > organization of nodes. > > Collections likely have other use-cases, though. I don't have a > solid reason to do away with them, yet. The generic properties of collections appeal to me intrinsically, they have already proven their value to me for my application, and I implemented them already for ejabberd (mostly - there are a couple of edges missing that I couldn't justify spending my time on.) So, for a bunch of reasons, I'm sold on them. I could probably be persuaded away, but I don't see how. -bjc From stpeter at stpeter.im Wed Feb 11 11:05:21 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 11 Feb 2009 10:05:21 -0700 Subject: [PubSub] PEP PIP PAP PUP -- POP! In-Reply-To: <4992F8A2.2050602@ik.nu> References: <4992EFA8.405@stpeter.im> <4992F8A2.2050602@ik.nu> Message-ID: <49930551.4020400@stpeter.im> Ralph Meijer wrote: > On 2009-02-11 16:32, Peter Saint-Andre wrote: >> I hate to pop your bubble, but I would suggest that we not get too hung >> up on marketing, which is all that the "Eventing" in PEP really is. >> >> (Backstory: I had a chat with Rohit Khare of KnowNow some years ago at a >> conference and he said it was a shame that the idea of publish-subscribe >> technologies hadn't taken off because they are so useful but needed a >> catchy name; I suggested "eventing" and then applied that to XEP-0163.) >> >> I don't think the "Eventing" in PEP means that every PEP node needs to >> be a singleton node (one item only), or that PEP can be used only for >> "personal" payload types. In fact I don't know if PEP really exists as a >> separate service. It's all just PubSub with various feature sets >> applied. If a given implementation of pubsub-on-a-jid (your bare JID is >> a virtual pubsub service) stores more than one item or even returns more >> than just the last published item on subscribe, what's the harm? > > I agree that there's more to "eventing" or node-tied-to-a-user-account > than what is currently defined in XEP-0163. However the terminology and > surrounding discussion is unclear, imprecise and often even plainly wrong. > > The only 'harm' I can see from a technical perspective is the '+notify' > feature, as I mentioned in another message: > > http://mail.jabber.org/pipermail/pubsub/2009-February/000097.html > > The only solution I can think of, is to redefine +notify to restrict on > node identifier, not on payload namespace. This probably coincides with > real-world use. I'd like to hear from implementors that followed the > specification to the letter. I think we already decided that at XMPP Summit #5 (Portland) after some discussion among implementors there. So version 1.12 of XEP-0060 has a revision note "Harmonized definition of +notify feature with implementation reality." > If the currently specified behavior of filtering on payload namespace is > still desired, we can think up a new suffix. Yes, like +filter. >> Perhaps it would help to think about these feature sets at a more >> granular level and apply them to various payload types or well-known >> NodeIDs. >> >> For example, for tunes publishing (XEP-0118) we might recommend that the >> NodeID shall be "http://jabber.org/protocol/tune", that the node shall >> send a notification on presence and on subscription but only send the >> last item, that we use the +notify caps extension to signal interest and >> establish temporary/implicit subscriptions, etc. > > One of the problems with the 'User *' specifications is that they both > define the payload format as well as one particular use of them. This > clouds other use cases. Agreed. However, I think we can clean them all up to describe those concerns separately (here's the payload, and here are a few ways you might use it). >> However, for public key publishing (XEP-0189) we might recommend a >> slightly different set of configuration options. >> >> I suppose the problem here is that the pubsub server would then need to >> know something about these well-known nodes instead of being completely >> generic. However, that seems consistent with the "simple clients, >> complex servers" philosophy that we tout so often, and it would apply >> only to well-known nodes. > > I think the problem is indeed in what the default node configuration is. > However, for example, XEP-0189 explicitly uses node configuration. You > could make the default node configuration for all nodes have the 'smart > defaults' that XEP-0163 dictates. For all other profiles that want to > deviate from those, you then require that they create nodes explicitly > with a node configuration and/or use the publish-options functionality. Right, but that can be pubsub-on-a-jid -- I don't think we want to restrict a virtual pubsub service associated with a bare JID to be all and only "PEP". If people really feel that we need separate profiles for rich-presence-like personal eventing (the current PEP), private data storage, etc., then we can do that, but over the long haul I think that might be more confusing than enlightening. Better, I think, to define how pubsub-on-a-jid can happen and what the nice defaults are for that functionality, but leave it up to the implementation or deployment to choose slightly different defaults across the whole service or at a particular node. The disadvantage, I suppose, is that rich presence might not work exactly as people expect (e.g., you might receive more than one published item when you subscribe or change your presence). But I wonder if things like PEP (XEP-0163), public data storage (XEP-0222), private data storage (XEP-0223), and so on really apply at the node level and not the service-wide level. If we went down that road (it's all about the nodes), the result would be that a tunes node has PEP semantics whereas a public key node has public data semantics, but you can't say definitively that the virtual pubsub service at user at example.com is "a PEP service" in the sense that every node there has PEP semantics. Yes, this is a bit more complex for pubsub services. On the other hand, I've come to realize that a client would add support for a given well-known node (tunes, moods, whatever) and not for "PEP" because each payload type is handled individually w.r.t. presentation in a GUI etc. > This at least is backwards compatible with PEP as currently defined. For > now I'm not in favor of making pubsub services 'smarter'. I'm in favor of defining reasonable semantics for a given payload type. For rich presence that is similar to presence (what's in PEP now). For Atom or public keys or whatever, that might be something different. But I need to think about it some more before I come to any hard conclusions on the topic... /psa -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/pubsub/attachments/20090211/960077b0/attachment-0001.bin From christophe.romain at process-one.net Wed Feb 11 12:30:36 2009 From: christophe.romain at process-one.net (Christophe Romain) Date: Wed, 11 Feb 2009 19:30:36 +0100 Subject: [PubSub] Brussels report In-Reply-To: <4992E882.5090308@ik.nu> References: <4992448D.30705@stpeter.im> <87y6wd87w0.fsf@phex.sachmittel.de> <4992CBAA.60808@stpeter.im> <4992D7A4.7040609@ik.nu> <87skml8377.fsf@phex.sachmittel.de> <4992E882.5090308@ik.nu> Message-ID: <20090211183036.GE6832@localhost> -- Ralph Meijer [2009-02-11 16:02:26 +0100]: > > E.g. ejabberd uses pubsub.server.tld and the (default) root node > > for a user is home/server.tld/username. How can a client know that? > > I want to make one point here about ejabberd's organisation of nodes, > although I don't know if recent versions still do this. In my opinion, > making node identifiers non-opaque in this way for a generic publish > subscribe service is confusing, limiting and sets a bad example. Limiting > because particular use cases, like transferring ownership of a node, are > impossible. I would even go as far as rating it broken. trunk version of ejabberd still to this as default. but it's just configuration issue. You can use a flat node organisation (as presented in XEP-0060) by using the flat plugin instead of the default plugin. next official release will use flat node organisation as default, so that standard pubsub installation will behave like documented in spec. From dmeyer at tzi.de Wed Feb 11 13:03:53 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Wed, 11 Feb 2009 20:03:53 +0100 Subject: [PubSub] Brussels report In-Reply-To: <4992E882.5090308@ik.nu> (Ralph Meijer's message of "Wed\, 11 Feb 2009 16\:02\:26 +0100") References: <4992448D.30705@stpeter.im> <87y6wd87w0.fsf@phex.sachmittel.de> <4992CBAA.60808@stpeter.im> <4992D7A4.7040609@ik.nu> <87skml8377.fsf@phex.sachmittel.de> <4992E882.5090308@ik.nu> Message-ID: <87zlgs7q3q.fsf@phex.sachmittel.de> Ralph Meijer wrote: > On 2009-02-11 15:21, Dirk Meyer wrote: >> Ralph Meijer wrote: >>> Nevertheless, the concept of providing nodes linked to user accounts, >>> where the those user accounts have their own jid of the form >>> user at service, still has great appeal. >>> >>> The general consensus seemed to be that we should keep PEP for the >>> limited use cases, while expanding server side implementations with >>> more features from XEP-0060. >>> >>> I'd really like a good short name/acronym for nodes on a user account, >>> by the way. It seems that a lot of confusion is there because some >>> people refer to just that feature as PEP. >> >> Right. I prefer PEP over "raw" PubSub because I do not have to search >> for a PubSub server and do not need to figure out where I can store >> stuff. > > You've just proven my point. Glad I could help with false knowledge :) > That said, nodes tied to a user account are not a feature unique to > PEP, but are defined in section 9 of XEP-0060. Maybe we need to define > a discovery feature to make this feature explicitly discoverable. +1 > Assuming nodes-tied-to-a-user-account is available, you still need > some way to know about the node names. This could be through discovery > or a search (XEP-0055 with data forms). However, well-known names seem > to have a strong preference. In this case, as you add support for a > particular feature in your client (e.g. User Tune), the node > identifier is known because it is defined by the specification. Right. For the public key publishing the node would be defined in XEP-0189 and would be something like 'certificates' for a list of certificates for my clients (readable for all friends in the roster) and 'contacts' for a list of friend certificates used for e2e (readable only for the user). > Recently, the text in section 9.2 (Filtered Notifications) was updated > to clarify how this feature works exactly, with this in a nice box: > > Note: In the context of personal eventing, the +notify feature means > that the subscriber will receive notifications only from the node > whose NodeID matches the desired namespace, because there is one node > per namespace and one namespace per node. > > Upon rethinking that phrase, it means that +notify breaks as soon as a > service implements more than just PEP and allows for more than one > node that publishes in a particular namespace (e.g. a Buddycloud-like > service that publishes to also publishes to a node that keeps a > location history). Unsuspecting PEP-only clients will suddenly receive > notifications from other nodes. That would be bad. Is nodename+notify a solution or does the feature has to be an xml namespace? Dirk -- You sound reasonable...Time to up my medication. From ralphm at ik.nu Wed Feb 11 13:05:19 2009 From: ralphm at ik.nu (Ralph Meijer) Date: Wed, 11 Feb 2009 20:05:19 +0100 Subject: [PubSub] Brussels report In-Reply-To: <5D46CD43-EC11-49F4-B4B0-0DC8523272D6@gmail.com> References: <4992448D.30705@stpeter.im> <094A847C-2C6A-4988-ADC8-61F7D6E2E812@gmail.com> <4992F1B1.7080403@ik.nu> <5D46CD43-EC11-49F4-B4B0-0DC8523272D6@gmail.com> Message-ID: <4993216F.5050801@ik.nu> On 2009-02-11 18:00, Brian Cully wrote: > On 11-Feb-2009, at 10:41, Ralph Meijer wrote: >> [..] > I really don't want there to be "special" NodeIDs; IOW, semantics > being mappable from NodeID directly. Down this path lay madness. I agree to some extend that making up well-known values, for node identifiers that should really be opaque, borders on being evil. However, bootstrapping subscriptions for the simple use cases PEP was designed for, becomes really painful if you must use Service Discovery to get to the node you want to subscribe to. Ideas welcome of course. > What happens when you need to internationalize, for instance? I'm not sure what problems i18n would cause here. > Who maintains the registrar? The XSF has a Registrar (http://xmpp.org/registrar/) as established by XEP-0053. > How do I use my own names w/o registering? The pattern to use namespace URIs for these well-known identifiers means that you can use URIs in your own domain. > Don't I have to deal with enough of this already? Uhm. I don't know really :-) > IMHO, out-of-band discovery makes the most sense (it's worked pretty > well for the web so far, though, admittedly, XMPP doesn't have the same > robust content-type negotiation). What kind of out-of-band discovery is used for the web, really? If I need to find your Twitter page, the best course of action is to search for your name on Google. I would hardly call that discovery, and arguably is in-band. >> Well, I'd like to see some solid use cases for having subscriptions >> depths of 'all'. The default is '1' and if you only implement that, >> the multi-graph is very shallow and way easier to implement on the >> server side. > > Depends on what you mean by "solid." I chose to implement it so my > clients would have a dead-simple API that was still flexible; we have a > node tree set up to allow you to subscribe for events at various > aggregation levels, depending on needs. That's nice and all, but what > most people are going to want to do is see everything they can. With > depth of "all" and type "items", you get that in one sub and no other > work. I think that's really sweet. > > So sweet, I even implemented it for ejabberd (see the "bjc/master" > branch of http://github.com/bjc/ejabberd), and the hard part there was > supporting depth "1" - the rest just fell out of the design. I'm pretty > sure OpenFire also implements sub depth and type, but I can't go check > right now. > > For the record, we chose DAG-style collections because of the > requirements of our service. We're publishing quite a lot of data which > every user gets a slightly different aggregation of. Doing a one-to-one > or one-to-many design would have resulted in a data explosion. By using > collection nodes in many-to-many fashion, we can keep one item on the > backend which publishes only to those who are supposed to see it by > virtue of the collection hierarchy. But, again, mostly our users are > going to want to see everything they can see, in other words, subscribe > to root, type "items," depth "all." What you describe here doesn't require collections at all and from the looks of it, you'd rather implement the scheme I described later in that mail. >> I agree you can't do away with both if you still want to be able >> subscribe with a subscription type of 'items'. That said, maybe only >> getting updates on new nodes or just for discoverability, collections >> could still be useful. > > You could do it either way. Personally, I like to keep the > complexity here in the server. It just seems like this is forcing > complexity on the client to save the time of server implementors. > There's a time and a place for that, but I don't think this is it. You might be right about that. >> The usefulness of collections was questioned by me, in the context of >> social network federation. >> >> In a generic publish subscribe service you create leaf and collection >> nodes to provide certain feeds to subscribe to. Items are explicitly >> published to one node (only) and notifications will always mention >> this node identifier, even if you subscribed through a collection. >> >> However, if XMPP publish-subscribe is 'just' another interface to your >> service, your implementation typically only uses the subscription and >> notification parts of the publish-subscribe protocol. I.e. you don't >> actually use the publishing protocol, but instead publishing magically >> happens internal to your service. > > I'm missing something here. How is using publish and subscribe not > using the publishing protocol? Does it make a difference if I retract > items, too? To abuse Roy Fielding, I'm "using PubSub as the engine of > application state." I wonder how that differs from what you mean by > "[using] the publishing protocol." Using the publish-subscribe design pattern is different from the publish-subscribe protocol. The pattern defines that there are topics, , items, subscribers and publishers, and how they interact. The protocol is just a way to talk to a service that happens to implement that pattern. You can send a request to let the server know you want updates on a particular topic (using ), publish new items to a topic (using ), or the server sends you notifications, with enclosed items, as the result of a subscription (using containers in a ). None of the above has to exist explicitly inside a service, and you also don't need to use all of the protocol to make stuff happen. E.g. all your items may come in via XMLRPC, but still yield notifications to subscribers via XMPP Publish-Subscribe messages with containers. >> In that case, nodes are an abstraction of your backend and a >> particular item just happens to yield notifications on multiple (leaf) >> nodes, without having a 'home' node. We coined this node-as-code. > > Can you give a more concrete example? This sounds vaguely like > something I might want, but I can't figure what you mean. Say I have a service like Jaiku. The feeds that entities might be interested in subscribing to, could be: 1. all items by ralphm 2. all items by ralphm and his friends 3. all items by my friends 4. all items Assuming I'm one of your friends (hi!), when I post something on the Jaiku web site, I want a notification to go out to subscribers of #1, #2, #3 and #4. All but #3 are explicit, as everybody subscribing to that those feeds would get the same notifications. However, #3 is special because 'my' depends on the point of view. All of these could be seen as a continuous query on the stream of incoming items, rather than explicit streams of items. In any case, though, as soon as the post comes in, I have to determine which entities will receive a notifications. Whether I make the routing explicit by defining how nodes relate to each other and have hierarchies, or that I just calculate where a particular item needs to go, doesn't really matter to the subscriber. It might be easier to calculate #2 using my contact list every time an item comes in, than to keep the collection organization up-to-date every time my contact list changes. Also, a lot of nodes might never be subscribed to, so having such nodes magically exist only when somebody tries to interact with it, could be a win. >> [..] >> >> Collections likely have other use-cases, though. I don't have a solid >> reason to do away with them, yet. > > The generic properties of collections appeal to me intrinsically, > they have already proven their value to me for my application, and I > implemented them already for ejabberd (mostly - there are a couple of > edges missing that I couldn't justify spending my time on.) So, for a > bunch of reasons, I'm sold on them. I could probably be persuaded away, > but I don't see how. See above :-) I don't know the specifics of your use cases, though. ralphm From ralphm at ik.nu Wed Feb 11 13:28:38 2009 From: ralphm at ik.nu (Ralph Meijer) Date: Wed, 11 Feb 2009 20:28:38 +0100 Subject: [PubSub] PEP PIP PAP PUP -- POP! In-Reply-To: <49930551.4020400@stpeter.im> References: <4992EFA8.405@stpeter.im> <4992F8A2.2050602@ik.nu> <49930551.4020400@stpeter.im> Message-ID: <499326E6.2080505@ik.nu> On 2009-02-11 18:05, Peter Saint-Andre wrote: > Ralph Meijer wrote: >> On 2009-02-11 16:32, Peter Saint-Andre wrote: >> [..] >> >> The only 'harm' I can see from a technical perspective is the '+notify' >> feature, as I mentioned in another message: >> >> http://mail.jabber.org/pipermail/pubsub/2009-February/000097.html >> >> The only solution I can think of, is to redefine +notify to restrict on >> node identifier, not on payload namespace. This probably coincides with >> real-world use. I'd like to hear from implementors that followed the >> specification to the letter. > > I think we already decided that at XMPP Summit #5 (Portland) after some > discussion among implementors there. So version 1.12 of XEP-0060 has a > revision note "Harmonized definition of +notify feature with > implementation reality." We did have this discussion, and I've seen the revision note, but that doesn't make the actual prose better. Apart from the boxed note, the description of the working of the filtering is still the same: you subscribe to everything and then the items are filtered on the namespace of the payload. The boxed note just says that it works like we want in PEP because there is only one node per namespace. >> If the currently specified behavior of filtering on payload namespace is >> still desired, we can think up a new suffix. > > Yes, like +filter. Right. >>> Perhaps it would help to think about these feature sets at a more >>> granular level and apply them to various payload types or well-known >>> NodeIDs. >>> >>> For example, for tunes publishing (XEP-0118) we might recommend that the >>> NodeID shall be "http://jabber.org/protocol/tune", that the node shall >>> send a notification on presence and on subscription but only send the >>> last item, that we use the +notify caps extension to signal interest and >>> establish temporary/implicit subscriptions, etc. >> One of the problems with the 'User *' specifications is that they both >> define the payload format as well as one particular use of them. This >> clouds other use cases. > > Agreed. However, I think we can clean them all up to describe those > concerns separately (here's the payload, and here are a few ways you > might use it). Right. Some of these specs also used to describe how you could send stuff directly via or even (horror!) , but that was taken out at some point. Let's indeed clean them up. >>> However, for public key publishing (XEP-0189) we might recommend a >>> slightly different set of configuration options. >>> >>> I suppose the problem here is that the pubsub server would then need to >>> know something about these well-known nodes instead of being completely >>> generic. However, that seems consistent with the "simple clients, >>> complex servers" philosophy that we tout so often, and it would apply >>> only to well-known nodes. >> I think the problem is indeed in what the default node configuration is. >> However, for example, XEP-0189 explicitly uses node configuration. You >> could make the default node configuration for all nodes have the 'smart >> defaults' that XEP-0163 dictates. For all other profiles that want to >> deviate from those, you then require that they create nodes explicitly >> with a node configuration and/or use the publish-options functionality. > > Right, but that can be pubsub-on-a-jid -- I don't think we want to > restrict a virtual pubsub service associated with a bare JID to be all > and only "PEP". No, I'm saying that the default node configurations of all pubsub-on-a-jid implementations would at least be compatible with the 'smart defaults' as defined in XEP-0163. The alternative is that existing PEP clients are going to discover stuff about the nodes they want to subscribe to, or create and publish to. This kind of negates the existence of XEP-0163. That may not be as bad, though. > If people really feel that we need separate profiles for > rich-presence-like personal eventing (the current PEP), private data > storage, etc., then we can do that, but over the long haul I think that > might be more confusing than enlightening. Better, I think, to define > how pubsub-on-a-jid can happen and what the nice defaults are for that > functionality, but leave it up to the implementation or deployment to > choose slightly different defaults across the whole service or at a > particular node. This would likely break existing client implementations as soon as those services would announce the pubsub/pep disco identity. > The disadvantage, I suppose, is that rich presence > might not work exactly as people expect (e.g., you might receive more > than one published item when you subscribe or change your presence). Exactly. > But I wonder if things like PEP (XEP-0163), public data storage (XEP-0222), > private data storage (XEP-0223), and so on really apply at the node > level and not the service-wide level. If we went down that road (it's > all about the nodes), the result would be that a tunes node has PEP > semantics whereas a public key node has public data semantics, but you > can't say definitively that the virtual pubsub service at > user at example.com is "a PEP service" in the sense that every node there > has PEP semantics. Yes, this is a bit more complex for pubsub services. I'm not against more logic on the server side, but this is about configurations, and that's data, not logic. I would rather have a generic solution without that data. The compromise that is XEP-0163 causes this mess, IMHO, and this is why I was so stubborn when we talked about it. As I mentioned before, the semantics for pubsub-on-a-jid should be a disco feature on its own. As I see it, the pubsub/pep disco identity implies this, but at the same time requires all nodes to share the XEP-0163 semantics, unless configured explicitly. > On the other hand, I've come to realize that a client would add support > for a given well-known node (tunes, moods, whatever) and not for "PEP" > because each payload type is handled individually w.r.t. presentation in > a GUI etc. Right. >> This at least is backwards compatible with PEP as currently defined. For >> now I'm not in favor of making pubsub services 'smarter'. > > I'm in favor of defining reasonable semantics for a given payload type. > For rich presence that is similar to presence (what's in PEP now). For > Atom or public keys or whatever, that might be something different. But > I need to think about it some more before I come to any hard conclusions > on the topic... We seem to disagree at this point. ralphm From romeda at gmail.com Thu Feb 12 06:44:35 2009 From: romeda at gmail.com (Blaine Cook) Date: Thu, 12 Feb 2009 12:44:35 +0000 Subject: [PubSub] Brussels report In-Reply-To: <4993216F.5050801@ik.nu> References: <4992448D.30705@stpeter.im> <094A847C-2C6A-4988-ADC8-61F7D6E2E812@gmail.com> <4992F1B1.7080403@ik.nu> <5D46CD43-EC11-49F4-B4B0-0DC8523272D6@gmail.com> <4993216F.5050801@ik.nu> Message-ID: On Wed, Feb 11, 2009 at 7:05 PM, Ralph Meijer wrote: >>> In that case, nodes are an abstraction of your backend and a particular >>> item just happens to yield notifications on multiple (leaf) nodes, without >>> having a 'home' node. We coined this node-as-code. >> >> Can you give a more concrete example? This sounds vaguely like >> something I might want, but I can't figure what you mean. > > In any case, though, as soon as the post comes in, I have to determine which > entities will receive a notifications. Whether I make the routing explicit > by defining how nodes relate to each other and have hierarchies, or that I > just calculate where a particular item needs to go, doesn't really matter to > the subscriber. > > It might be easier to calculate #2 using my contact list every time an item > comes in, than to keep the collection organization up-to-date every time my > contact list changes. Also, a lot of nodes might never be subscribed to, so > having such nodes magically exist only when somebody tries to interact with > it, could be a win. To generalize, and expose some of the thinking that drove me to the conclusion that node-as-code is better than publishing to explicit nodes, take web servers and CGI as an example. When a user makes a request, the web server's job is to hide some of the protocol-level complexity of the request, and pass the necessary processing information (usually a URI plus a body, and some extra stuff) over CGI to some code. The code runs, evaluates context dynamically, and the user gets a response based on a relatively complex set of requirements. Now consider an alternate view: in order to publish data, you create a node on a black-box server, possibly within a collection. You publish a security policy to that node, and then data. When users request the data, the black box server evaluates the user's identity, and decides whether or not they can see the data. Any possibility of flexible treatment of data is lost, and the developer's work is transformed from writing code to designing complicated policies that pre-meditate every possible use-case. Sometimes that works, and in fact most caching systems operate somewhere between the two scenarios. Currently, most conceptions of XMPP PubSub operate firmly in the latter scenario, hence the need for a conception of code-driven PubSub. Now, I don't think that the spec needs any changing at all in order to support this behaviour; all you end up doing is ignoring large swathes of specification. In fact, the Fire Eagle XMPP PubSub mechanism operates in exactly this way, interacting with ejabberd as a component, and using only the s2s functionality of ejabberd. It works well (I think? Seth? ;-) ), and is only a few hundred lines of code. b. From seth at mojodna.net Thu Feb 12 10:16:38 2009 From: seth at mojodna.net (Seth Fitzsimmons) Date: Thu, 12 Feb 2009 08:16:38 -0800 Subject: [PubSub] Brussels report In-Reply-To: References: <4992448D.30705@stpeter.im> <094A847C-2C6A-4988-ADC8-61F7D6E2E812@gmail.com> <4992F1B1.7080403@ik.nu> <5D46CD43-EC11-49F4-B4B0-0DC8523272D6@gmail.com> <4993216F.5050801@ik.nu> Message-ID: <1d7d37050902120816y498b3f15pa9433946ba1e2479@mail.gmail.com> > Sometimes that works, and in fact most caching systems operate > somewhere between the two scenarios. Currently, most conceptions of > XMPP PubSub operate firmly in the latter scenario, hence the need for > a conception of code-driven PubSub. Now, I don't think that the spec > needs any changing at all in order to support this behaviour; all you > end up doing is ignoring large swathes of specification. In fact, the > Fire Eagle XMPP PubSub mechanism operates in exactly this way, > interacting with ejabberd as a component, and using only the s2s > functionality of ejabberd. It works well (I think? Seth? ;-) ), and > is only a few hundred lines of code. Yes, Fire Eagle works this way, and it's very similar to the approach that I've been thinking about for other projects. One limitation in the spec that I periodically bump into is that collection nodes shouldn't have items associated with them. The particular use-cases are: - node hierarchies (maybe), i.e. supporting requests on parent nodes to retrieve all children - making individual resources (in the REST sense) available as nodes (/people/seth where "seth" is actually an item on the /people node). Semantics around collectionS nodes get weird; I publish to /people with id=seth, I retrieve with an request on /people/seth (since I can't retrieve a specific id from /people), I can either update /people/seth OR re-publish with id=seth to /people, and I can retract from /people with id=seth OR retract from /people/seth OR purge /people/seth. I have a rough XMPP-rack bridge here that demonstrates how PubSub semantics are mapped to resources (the controller at the end of it is a straightforward Rails resource controller (mars; usage notes are there)): http://github.com/mojodna/dovetail/blob/4ee9fcf930193c4dadd506005facec98d73b8ca8/lib/dovetail.rb http://github.com/mojodna/mars/tree/master Strictly speaking, /people should be a collection node and shouldn't have items / be manipulable, but I can't get around this sufficiently. XEP 248 is much more complicated (and limiting) than I need for node-as-code. The implementation specifics of the black box should be hidden from consumers and can either be exposed to publishers (for traditional PubSub-style manipulation) or be embedded in application code, in which case there's no benefit in exposing them. Ignoring swaths of specs is one thing (i.e. not supporting them), but implementing a service in such a way that behavior is contradictory is another, so my preference would be for the spec to be more lenient to support the whole node-as-code usecase. The component implementation is actually a giant pile of pain (this is not PubSub-specific, but still relevant). I'd rather *not* have to deal with discovery, ping, roster handling (beyond setting a default policy), or presence tracking by default. There are cases where I may decide that I need to, but I would much prefer if I had the option to, rather than the requirement. I think it also results in component implementations of varying quality, because each developer needs to almost entirely reinvent the wheel. (That said, *having* a component option is wonderful, but I long for a half-way solution). I've been thinking about this recently and would like to see something along the lines of a CGI, Rack, WSGI, or Servlet specification for PubSub-specific functionality. Somewhat along the lines of what Julien Genestoux and Stephan Maka have done with Babylon (http://github.com/julien51/babylon), but built into servers and with a clearly defined, language agnostic interface. It would involve routing/mapping of PubSub nodes (patterns, really) to *something* (I'm leaning towards either queues or URIs (*not* limited to HTTP), with different schemes supported by different servers). The mapping would either be static (application configuration) or dynamic (processors register patterns that they know how to process). The payload (and response) would probably be XML or JSON; I think it needs to contain more context (such as the known presence for the requesting JID) than just the stanza, but I haven't given this a whole lot of thought yet. If I have some time (ha!), I'd like to talk a bit more with Julien and try to hack out a prototype to figure out what the issues are using Wokkel or Tigase. seth From stpeter at stpeter.im Thu Feb 12 12:37:37 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 12 Feb 2009 11:37:37 -0700 Subject: [PubSub] Apple's Push Notification Server Message-ID: <49946C71.3040402@stpeter.im> A rumor of interest.... http://www.appleinsider.com/articles/09/02/11/iphone_push_notification_server_tied_to_snow_leopard_server.html&page=2 /psa -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/pubsub/attachments/20090212/a12d08fe/attachment.bin From ralphm at ik.nu Fri Feb 13 13:13:05 2009 From: ralphm at ik.nu (Ralph Meijer) Date: Fri, 13 Feb 2009 20:13:05 +0100 Subject: [PubSub] Brussels report In-Reply-To: <1d7d37050902120816y498b3f15pa9433946ba1e2479@mail.gmail.com> References: <4992448D.30705@stpeter.im> <094A847C-2C6A-4988-ADC8-61F7D6E2E812@gmail.com> <4992F1B1.7080403@ik.nu> <5D46CD43-EC11-49F4-B4B0-0DC8523272D6@gmail.com> <4993216F.5050801@ik.nu> <1d7d37050902120816y498b3f15pa9433946ba1e2479@mail.gmail.com> Message-ID: <4995C641.6040709@ik.nu> On 2009-02-12 17:16, Seth Fitzsimmons wrote: >> Sometimes that works, and in fact most caching systems operate >> somewhere between the two scenarios. Currently, most conceptions of >> XMPP PubSub operate firmly in the latter scenario, hence the need for >> a conception of code-driven PubSub. Now, I don't think that the spec >> needs any changing at all in order to support this behaviour; all you >> end up doing is ignoring large swathes of specification. In fact, the >> Fire Eagle XMPP PubSub mechanism operates in exactly this way, >> interacting with ejabberd as a component, and using only the s2s >> functionality of ejabberd. It works well (I think? Seth? ;-) ), and >> is only a few hundred lines of code. > > Yes, Fire Eagle works this way, and it's very similar to the approach > that I've been thinking about for other projects. One limitation in > the spec that I periodically bump into is that collection nodes > shouldn't have items associated with them. The particular use-cases > are: > - node hierarchies (maybe), i.e. supporting requests on > parent nodes to retrieve all children > - making individual resources (in the REST sense) available as nodes > (/people/seth where "seth" is actually an item on the /people node). First of all, REST does not dictate that the identification of a particular resource needs to be done solely in the path component of an HTTP URI. This follows naturally from RFC 3986 (and its predecessors) describing URI generic syntax. I'll start with some background to base my response on, if only for readers not so entrenched in this stuff. In XMPP the identification of resources is essentially threefold: the JID of the service, the identifier of the node and the identifier of an item. Those can be combined into an XMPP URI to fully denote the resource in one identifier, although currently there is no XMPP URI query parameter defined for item identifiers. Whereas the typical uses of HTTP URIs usually nicely maps on filesystem layouts with files and directories, where directories can contain both directories and files, XMPP publish subscribe nodes and items are just slightly different. If you would want to map those on filesystem semantics, items would be files and nodes would be directories. Leaf nodes only contain items ('files'), and collections can only contain other nodes ('directories'). I don't think it is particularly needed to always map all resources to nodes. This totally depends on the 'subscribable unit' [1]. > Semantics around collection nodes get weird; I publish to /people > with id=seth, I retrieve with an request on /people/seth > (since I can't retrieve a specific id from /people), I can either > update /people/seth OR re-publish with id=seth to /people, and I can > retract from /people with id=seth OR retract from /people/seth OR > purge /people/seth. If you want to allow entities to subscribe to updates on only particular individual resources (say 'seth'), you should provide them as a node. That this node then will only ever have one item in it, is not a problem. We have several uses of this in extended presence publishing via PEP, where you only ever publish the current mood, current location, etc. We use this model at Mediamatic Lab for sharing 'things' between anyMeta sites in the Open-CI network [2]. Every thing (person, article, organization, event) has its own node where updates are published to as Atom entry documents. We currently use opaque node identifiers, but are likely moving to a more integrated solutions in the near future. > I have a rough XMPP-rack bridge here that demonstrates how PubSub > semantics are mapped to resources (the controller at the end of it is > a straightforward Rails resource controller (mars; usage notes are > there)): > http://github.com/mojodna/dovetail/blob/4ee9fcf930193c4dadd506005facec98d73b8ca8/lib/dovetail.rb > http://github.com/mojodna/mars/tree/master Interesting. I have to take a closer look, though. > Strictly speaking, /people should be a collection node and shouldn't > have items / be manipulable, but I can't get around this sufficiently. The use cases you present are probably covered by the following series of questions: 1. What are the things an end-user is going to subscribe to? 2. How do I represent feeds of updates to multiple things? 3. How do I retrieve items from a feed? 4. How do I publish and/or retract things? In what I've described above about what we do at Mediamatic Lab, or the things I wrote about node-as-code, I have not really addressed the publishing side of things. In that case, questions #1 and #2 become relatively easy. Objects just magically appear inside your backend. Every time a new (or updated) object appears in the backend, you can just send out notifications to subscribers of feeds like 'things by ralphm', 'things by all people', 'things by ralphm and his friends'. Each of those feeds would be a leaf node, with the item being 'published' to each of those. Retrieving items (#3) in this case is easy. As each node is a leaf node, you can just do a regular request. The advantage of this approach is that you don't need to explicitly keep the configuration of the hierarchy. In your example, new persons would just automatically be notified from the 'people' feed. On the other hand, when #4, publishing and/or retracting things, comes into the picture, things may become tricky. In this case, you likely want exactly one node to publish to, whereas the nodes-as-code would essentially be read only. I can see why collections might be attractive in this scenario. Collections are read only, and notifications will always have the node identifier where the item is 'home' and was published to. Like leaf nodes, the configuration of collection nodes might also be computed. Unfortunately, with how the protocol is defined at this moment, this doesn't play nice with #3, as you suggested. Basically, requests are not defined for collection nodes. I.e. the return format is not capable of conveying the node identifier of the original descendant node of the items it would return. Ordering might also be interesting, but that is an application level issue. As Blaine mentioned to me the other day, pubsub without the ability to retrieve items after the fact, can be very painful. I see two solutions here: 1. Add an optional 'node' attribute to the element in the http://jabber.org/protocols/pubsub namespace to convey the node this item was actually published to. I would define the semantics such that it overrides the 'node' attribute of the containing attribute. 2. Don't return the results in the response, but instead send them asynchronously. I tend towards the first solution. Looking at the schema for the element in the http://jabber.org/protocols/pubsub#event namespace, I note that there is a 'node' attribute there. This is likely a remnant of earlier version of the specification, since we currently use SHIM headers to communicate the node that was subscribed to. The reasoning behind that was that a particular notification can be the result of multiple subscriptions, to the same node (in which case you have multiple 'SubID' headers) and/or to different collection nodes (in which case you have multiple 'Collection' headers?). The latter is not explicitly defined in XEP-0248. How you should communicate which SubID belongs to which Collection, if both come in multiples is also not defined. > XEP 248 is much more complicated (and limiting) than I need for > node-as-code. > > The implementation specifics of the black box should be hidden from > consumers and can either be exposed to publishers (for traditional > PubSub-style manipulation) or be embedded in application code, in > which case there's no benefit in exposing them. > > Ignoring swaths of specs is one thing (i.e. not supporting them), but > implementing a service in such a way that behavior is contradictory is > another, so my preference would be for the spec to be more lenient to > support the whole node-as-code usecase. I understand this sentiment, but I'm not sure how to address this, yet. XEP-0248 needs a long hard look anyway, something Joe Hildebrand and I concluded at XMPP Summit #5. If you have any more notes on this, starting a new thread might be a good start. > The component implementation is actually a giant pile of pain (this is > not PubSub-specific, but still relevant). I'd rather *not* have to > deal with discovery, ping, roster handling (beyond setting a default > policy), or presence tracking by default. There are cases where I may > decide that I need to, but I would much prefer if I had the option to, > rather than the requirement. I think it also results in component > implementations of varying quality, because each developer needs to > almost entirely reinvent the wheel. (That said, *having* a component > option is wonderful, but I long for a half-way solution). Implementing a generic publish-subscribe service by itself does not necessitate roster handling and presence tracking, unless you want to have presence based subscriptions or nodes-tied-to-user-accounts (like PEP) with its associated access models based on rosters. Idavoll is an example of this. I don't know why you would need to implement ping. The amount of Service Discovery that you MUST implement for XEP-0060 is limited to announcing the features of the service in disco#info. You don't necessarily have to return any results to disco#items requests. I'm not sure what you are getting at here, for components in general, though. Or do you mean a specific implementation? > I've been thinking about this recently and would like to see something > along the lines of a CGI, Rack, WSGI, or Servlet specification for > PubSub-specific functionality. Somewhat along the lines of what > Julien Genestoux and Stephan Maka have done with Babylon > (http://github.com/julien51/babylon), but built into servers and with > a clearly defined, language agnostic interface. Yeah, I've more ideas along those lines around the Summit and am very interested in participating in such an effort. > It would involve routing/mapping of PubSub nodes (patterns, really) to > *something* (I'm leaning towards either queues or URIs (*not* limited > to HTTP), with different schemes supported by different servers). The > mapping would either be static (application configuration) or dynamic > (processors register patterns that they know how to process). The > payload (and response) would probably be XML or JSON; I think it needs > to contain more context (such as the known presence for the requesting > JID) than just the stanza, but I haven't given this a whole > lot of thought yet. Indeed, something like this would be nice. I don't think it would be very hard to implement the 'server side' in Twisted, to be added to Idavoll. The 'client side' could be very much like a WSGI client. > If I have some time (ha!), I'd like to talk a bit more with Julien and > try to hack out a prototype to figure out what the issues are using > Wokkel or Tigase. Let me know when you do. A groupchat might be an idea? ralphm PS. If you got all the way here, I congratulate you. It took me most of the day to write this. From ka-el at laposte.net Tue Feb 17 15:56:14 2009 From: ka-el at laposte.net (kael) Date: Tue, 17 Feb 2009 22:56:14 +0100 Subject: [PubSub] xCal over XMPP a.k.a Pubsub calendar / Time-based Pubsub notification Message-ID: <499B327E.1060405@laposte.net> Peter Saint-Andre wrote: > A rumor of interest.... > > http://www.appleinsider.com/articles/09/02/11/iphone_push_notification_server_tied_to_snow_leopard_server.html&page=2 How about standardizing xCal over XMPP a.k.a Pubsub calendar ? PUBLISH 2.0 -//HandGen//NONSGML vGen v1.0//EN 19981116T150000 at cal10.host.com 19981116T145958Z Project XYZ Review Conference Room 23A 19981116T163000Z 19981116T190000Z 1998-ABC Corp-1234 Appointment,Work There could be as many nodes as there are calendar events types. It might be possible to use XMPP-to-SyncML (and perhaps a XMPP-to-CalDAV) gateways. Calendars could be shared in a granular and flexible way. Additionally to XMPP Pubsub event notifications, there could be a new time-based Pubsub delivery mechanism that would allow to publish items without immediate notification but based on an date contained in the Pubsub stanza. A time-based Pubsub notification mechanism would allow to load calendars and other time-based databases (like an XML Electronic Programme Guide) as Pubsub trees. It would thus be possible to browse these time-based databases as grids/data-stores. - _iCalendar in XML Format_ : ; - _XMLTV_ : ; - _BBC Programme Ontology over XMPP_ : ; - _EPGXML_ : . -- kael From stpeter at stpeter.im Thu Feb 19 13:25:38 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 19 Feb 2009 12:25:38 -0700 Subject: [PubSub] xCal over XMPP a.k.a Pubsub calendar / Time-based Pubsub notification In-Reply-To: <499B327E.1060405@laposte.net> References: <499B327E.1060405@laposte.net> Message-ID: <499DB232.6020302@stpeter.im> kael wrote: > How about standardizing xCal over XMPP a.k.a Pubsub calendar ? I talked with a guy from Sun about this at FOSDEM. I think it is a very interesting and valuable use case. Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/pubsub/attachments/20090219/169edf33/attachment.bin From jehan at zemarmot.net Thu Feb 19 13:38:27 2009 From: jehan at zemarmot.net (Jehan) Date: Thu, 19 Feb 2009 20:38:27 +0100 Subject: [PubSub] xCal over XMPP a.k.a Pubsub calendar / Time-based Pubsub notification In-Reply-To: <499DB232.6020302@stpeter.im> References: <499B327E.1060405@laposte.net> <499DB232.6020302@stpeter.im> Message-ID: <023d15a74efd34c556a229ac9abfb8a9@localhost> Yes I really think that a calendar over XMPP could be nice! Jehan On Thu, 19 Feb 2009 12:25:38 -0700, Peter Saint-Andre wrote: > kael wrote: > >> How about standardizing xCal over XMPP a.k.a Pubsub calendar ? > > I talked with a guy from Sun about this at FOSDEM. I think it is a very > interesting and valuable use case. > > Peter -- Que la Sainte Marmotte soit avec moi! Pour me contacter: T?l: 06 81 89 41 20 IM: jehan at zemarmot.net email: jehan at zemarmot.net http://jehan.zemarmot.net From seth at mojodna.net Fri Feb 20 18:07:29 2009 From: seth at mojodna.net (Seth Fitzsimmons) Date: Fri, 20 Feb 2009 16:07:29 -0800 Subject: [PubSub] Fire Eagle Location Streams Message-ID: <1d7d37050902201607w42f890c6j983b112303228940@mail.gmail.com> FYI, we "officially" announced our XMPP PubSub (+OAuth) implementation (coined "Location Streams" on the spur of the moment) yesterday: http://feblog.yahoo.net/2009/02/19/fire-eagle-location-streams/ seth From romeda at gmail.com Fri Feb 20 18:26:50 2009 From: romeda at gmail.com (Blaine Cook) Date: Sat, 21 Feb 2009 00:26:50 +0000 Subject: [PubSub] Fire Eagle Location Streams In-Reply-To: <1d7d37050902201607w42f890c6j983b112303228940@mail.gmail.com> References: <1d7d37050902201607w42f890c6j983b112303228940@mail.gmail.com> Message-ID: Which is awesome, just saying. The blog post is particularly good, y'all should read it if you haven't. :-) b. On Sat, Feb 21, 2009 at 12:07 AM, Seth Fitzsimmons wrote: > FYI, we "officially" announced our XMPP PubSub (+OAuth) implementation > (coined "Location Streams" on the spur of the moment) yesterday: > http://feblog.yahoo.net/2009/02/19/fire-eagle-location-streams/ > > seth > From xma at gnu.org Wed Feb 25 17:25:03 2009 From: xma at gnu.org (Xavier Maillard) Date: Thu, 26 Feb 2009 00:25:03 +0100 Subject: [PubSub] xCal over XMPP a.k.a Pubsub calendar / Time-based Pubsub notification In-Reply-To: message from Jehan on Thu, 19 Feb 2009 20:38:27 +0100 Message-ID: <200902252325.n1PNP39s029797@zogzog.maillard.mobi> Yes I really think that a calendar over XMPP could be nice! +1. This is the kind of "killer feature" I would like to have... Xavier -- http://www.gnu.org http://www.april.org http://www.lolica.org