From robincollier at hotmail.com Fri May 1 12:48:36 2009 From: robincollier at hotmail.com (Robin Collier) Date: Fri, 1 May 2009 13:48:36 -0400 Subject: [PubSub] item schema in the #event namespace Message-ID: I don't see any purpose for the 'node' attribute in this schema. The 'item' element can only be contained within the 'items' element which has a 'node' attribute. There are no examples that would show any purpose for such an attribute, and any such usage is potentially contradictory to the value of the 'node' in the parent 'items' element. _________________________________________________________________ Internet explorer 8 lets you browse the web faster. http://go.microsoft.com/?linkid=9655582 -------------- next part -------------- An HTML attachment was scrubbed... URL: From robincollier at hotmail.com Wed May 13 14:31:28 2009 From: robincollier at hotmail.com (Robin Collier) Date: Wed, 13 May 2009 15:31:28 -0400 Subject: [PubSub] Example PubSub service to publish BBC World News In-Reply-To: <1d142be30904301000o662a04f4xc92aedff9eec7fc9@mail.gmail.com> References:

<1d142be30904301000o662a04f4xc92aedff9eec7fc9@mail.gmail.com> Message-ID: > Date: Thu, 30 Apr 2009 19:00:14 +0200 > From: koski.tuomas at gmail.com > To: pubsub at xmpp.org > Subject: Re: [PubSub] Example PubSub service to publish BBC World News > > Hi Guys, > > 2009/4/30 Robin Collier : > > I have almost completed a pubsub extension to Smack and will be submitting > > it as a patch in a week or two. It does not actually change the existing > > smack > > libraries, so it can be used along with the existing version (3.1) by simply > > including the additional jar file. It is compliant to pubsub version 1.12 > > though, > > so I have had to make a few upgrades and fixes to OpenFire as well for it to > > work properly (since the current supported version is earlier than that). > > > > I would be happy to share that jar and get any input on the API when it is > > ready. > > > > Robin > > That's excellent news Robin. Don't hesitate to tell when it's ready :-D It's ready. Available at http://www.igniterealtime.org/community/thread/38433. > > And now when I'm writing here, there are couple of new services > available (as they were requested): > * slashdot at xmpp.lobsermonster.org (http://slashdot.org/firehose_recent.rss) > * 20minutos at xmpp.lobsermonster.org (spanish: http://www.20minutos.es/rss/) > * yle-uutiset at xmpp.lobsermonster.org (finnish: http://www.20minutos.es/rss/) > * yle-urheilu at xmpp.lobsermonster.org (finnish: > http://www.yle.fi/urheilu/rss/urheilu_uutiset_tuoreimmat.xml) > > > br, > -- > tuomas _________________________________________________________________ Internet explorer 8 lets you browse the web faster. http://go.microsoft.com/?linkid=9655582 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcully at gmail.com Fri May 15 16:57:56 2009 From: bcully at gmail.com (Brian Cully) Date: Fri, 15 May 2009 17:57:56 -0400 Subject: [PubSub] [Standards] Pubsub feature add: get default subscription configuration In-Reply-To: <49E7468B.6080003@stpeter.im> References: <4940D5E1.2090200@yahoo.com> <49E7468B.6080003@stpeter.im> Message-ID: In my world, subscription option defaults are better left relegated to a node, as nodes may then be able to calculate appropriate defaults based on their semantics, which may be different from node to node within a given pubsub service. -bjc On Apr 16, 2009, at 10:54, Peter Saint-Andre wrote: > On 12/11/08 1:57 AM, Brett Zamir wrote: >> Given the Subscribe-and-Configure option in Pubsub (at >> http://xmpp.org/extensions/xep-0060.html#subscriber-configure-subandconfig >> ), would it not make sense to be able to get a set of default >> values for >> subscription configuration, just as there is with default node >> configuration: http://xmpp.org/extensions/xep-0060.html#owner- >> default ? >> Granted, with node creation, there is no node to query ahead of >> time as >> is possible with subscription options, but a client might find it >> helpful to know the usual configuration to start with... > > I don't know how useful this really is. However, the following > defaults > seem reasonable to me: > > pubsub#deliver => TRUE > > pubsub#digest => FALSE > > pubsub#include_body => TRUE > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > From stpeter at stpeter.im Mon May 18 17:39:42 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Mon, 18 May 2009 16:39:42 -0600 Subject: [PubSub] [Standards] Pubsub feature add: get default subscription configuration In-Reply-To: References: <4940D5E1.2090200@yahoo.com> <49E7468B.6080003@stpeter.im> Message-ID: <4A11E3AE.7020608@stpeter.im> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/15/09 3:57 PM, Brian Cully wrote: > In my world, subscription option defaults are better left relegated to a > node, as nodes may then be able to calculate appropriate defaults based > on their semantics, which may be different from node to node within a > given pubsub service. That does seem more reasonable: you ping the node for default subscription configuration options and you ping the service for default node configuration options. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoR464ACgkQNL8k5A2w/vyjYQCfYWRhlZ3ByOKyb3+H8hkOhVKu NpYAnREdOAIHYTMjLoIr0zntYiM0BT6M =aRPB -----END PGP SIGNATURE----- From stpeter at stpeter.im Tue May 19 13:36:15 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 19 May 2009 12:36:15 -0600 Subject: [PubSub] Apple's Push Notification service Message-ID: <4A12FC1F.401@stpeter.im> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Of interest. http://www.appleinsider.com/articles/09/05/18/apple_begins_stress_testing_iphone_3_0_push_notifications.html Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoS/B8ACgkQNL8k5A2w/vyKUwCg9lq8yxjgSUH86Ud6I2HU2C/3 cV4AoNgnx/PDMtloXMb36QvhcGbH6xcp =37/N -----END PGP SIGNATURE----- From nathanfritz at gmail.com Tue May 19 13:38:00 2009 From: nathanfritz at gmail.com (Nathan Fritz) Date: Tue, 19 May 2009 11:38:00 -0700 Subject: [PubSub] Apple's Push Notification service In-Reply-To: <4A12FC1F.401@stpeter.im> References: <4A12FC1F.401@stpeter.im> Message-ID: <182eea400905191138o1468c679mf1f8630c509dec31@mail.gmail.com> > > http://www.appleinsider.com/articles/09/05/18/apple_begins_stress_testing_iphone_3_0_push_notifications.html > This earlier article http://www.appleinsider.com/articles/09/02/11/iphone_push_notification_server_tied_to_snow_leopard_server.htmlalso chimes in on the subject. -Fritz -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at spicenitz.org Wed May 20 14:16:49 2009 From: adam at spicenitz.org (Adam Goode) Date: Wed, 20 May 2009 15:16:49 -0400 Subject: [PubSub] multicast publish? Message-ID: <4A145721.3000109@spicenitz.org> Hi, From the schema in XEP-0060, it looks like I can legally put multiple elements within a single element. Is this behavior allowed? I would to have the effect of an atomic posting to many nodes at once, with failure of one publish cancelling all publishing (like in 12.9 Batch Processing). There is some precedent, with putting multiple elements in a . I don't see why this shouldn't work. Thoughts? Thanks, Adam From stpeter at stpeter.im Wed May 20 14:21:37 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 20 May 2009 13:21:37 -0600 Subject: [PubSub] multicast publish? In-Reply-To: <4A145721.3000109@spicenitz.org> References: <4A145721.3000109@spicenitz.org> Message-ID: <4A145841.5090403@stpeter.im> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/20/09 1:16 PM, Adam Goode wrote: > Hi, > > From the schema in XEP-0060, it looks like I can legally put multiple > elements within a single element. Is this behavior > allowed? I would to have the effect of an atomic posting to many nodes > at once, with failure of one publish cancelling all publishing (like in > 12.9 Batch Processing). > > There is some precedent, with putting multiple elements in a > . I don't see why this shouldn't work. > > Thoughts? This sounds like a bad idea to me -- what kind of error handling will the service be able to provide? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoUWEEACgkQNL8k5A2w/vxZ1wCdEPSvG0FCn+l+DPCdKYHwNdpc AcAAnR2USK8xC9H6iSG0Mak10XGq5Cw/ =3T/F -----END PGP SIGNATURE----- From adam at spicenitz.org Wed May 20 14:28:03 2009 From: adam at spicenitz.org (Adam Goode) Date: Wed, 20 May 2009 15:28:03 -0400 Subject: [PubSub] multicast publish? In-Reply-To: <4A145841.5090403@stpeter.im> References: <4A145721.3000109@spicenitz.org> <4A145841.5090403@stpeter.im> Message-ID: <4A1459C3.4010308@spicenitz.org> On 05/20/2009 03:21 PM, Peter Saint-Andre wrote: > On 5/20/09 1:16 PM, Adam Goode wrote: >> Hi, >> >> From the schema in XEP-0060, it looks like I can legally put multiple >> elements within a single element. Is this behavior >> allowed? I would to have the effect of an atomic posting to many nodes >> at once, with failure of one publish cancelling all publishing (like in >> 12.9 Batch Processing). >> >> There is some precedent, with putting multiple elements in a >> . I don't see why this shouldn't work. >> >> Thoughts? > > This sounds like a bad idea to me -- what kind of error handling will > the service be able to provide? > Do you mean how will the publisher know which nodes failed? I guess the iq error message tells you that the pubsub failed, but not which items. What happens if a multi-item publish fails? Adam From stpeter at stpeter.im Wed May 20 14:48:43 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 20 May 2009 13:48:43 -0600 Subject: [PubSub] multicast publish? In-Reply-To: <4A1459C3.4010308@spicenitz.org> References: <4A145721.3000109@spicenitz.org> <4A145841.5090403@stpeter.im> <4A1459C3.4010308@spicenitz.org> Message-ID: <4A145E9B.3060704@stpeter.im> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/20/09 1:28 PM, Adam Goode wrote: > On 05/20/2009 03:21 PM, Peter Saint-Andre wrote: >> On 5/20/09 1:16 PM, Adam Goode wrote: >>> Hi, >>> >>> From the schema in XEP-0060, it looks like I can legally put multiple >>> elements within a single element. Is this behavior >>> allowed? I would to have the effect of an atomic posting to many nodes >>> at once, with failure of one publish cancelling all publishing (like in >>> 12.9 Batch Processing). >>> >>> There is some precedent, with putting multiple elements in a >>> . I don't see why this shouldn't work. >>> >>> Thoughts? >> >> This sounds like a bad idea to me -- what kind of error handling will >> the service be able to provide? >> > > Do you mean how will the publisher know which nodes failed? I guess the > iq error message tells you that the pubsub failed, but not which items. > > What happens if a multi-item publish fails? Same problem -- the publish is not atomic. Thus I would discourage multi-item publish, too. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoUXpsACgkQNL8k5A2w/vx6bwCeMKBqAlC+5gXEHO1Y6OeAmZGy z0AAoONHtzHKm3Tf0lh83fAqhFL2jVGd =TZhP -----END PGP SIGNATURE----- From adam at spicenitz.org Wed May 20 22:45:05 2009 From: adam at spicenitz.org (Adam Goode) Date: Wed, 20 May 2009 23:45:05 -0400 Subject: [PubSub] multicast publish? In-Reply-To: <4A145E9B.3060704@stpeter.im> References: <4A145721.3000109@spicenitz.org> <4A145841.5090403@stpeter.im> <4A1459C3.4010308@spicenitz.org> <4A145E9B.3060704@stpeter.im> Message-ID: <4A14CE41.8040504@spicenitz.org> On 05/20/2009 03:48 PM, Peter Saint-Andre wrote: > On 5/20/09 1:28 PM, Adam Goode wrote: >> On 05/20/2009 03:21 PM, Peter Saint-Andre wrote: >>> On 5/20/09 1:16 PM, Adam Goode wrote: >>>> Hi, >>>> >>>> From the schema in XEP-0060, it looks like I can legally put multiple >>>> elements within a single element. Is this behavior >>>> allowed? I would to have the effect of an atomic posting to many nodes >>>> at once, with failure of one publish cancelling all publishing (like in >>>> 12.9 Batch Processing). >>>> >>>> There is some precedent, with putting multiple elements in a >>>> . I don't see why this shouldn't work. >>>> >>>> Thoughts? >>> This sounds like a bad idea to me -- what kind of error handling will >>> the service be able to provide? >>> >> Do you mean how will the publisher know which nodes failed? I guess the >> iq error message tells you that the pubsub failed, but not which items. > >> What happens if a multi-item publish fails? > > Same problem -- the publish is not atomic. Thus I would discourage > multi-item publish, too. :) Ok. Sounds reasonable. But does this disagree with the wording in XEP-0060: If the service cannot process any one of the items to be published or retracted, the entire batch MUST fail and the service MUST NOT publish or retract any of the items. ? Thanks, Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From robincollier at hotmail.com Fri May 22 12:13:20 2009 From: robincollier at hotmail.com (Robin Collier) Date: Fri, 22 May 2009 13:13:20 -0400 Subject: [PubSub] Timestamps on items Message-ID: Wouldn't it make sense to have a timestamp on an item? When a get items request is sent to a persistent node, there is no way to know when the item was published. I don't think it is necessary for live events, but I think it should be included for items that were published in the past. After all, it is already required to produce the date for an event that is denoted as delayed. _________________________________________________________________ Find info faster and easier with Internet Explorer 8. http://go.microsoft.com/?linkid=9655583 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathanfritz at gmail.com Fri May 22 13:18:12 2009 From: nathanfritz at gmail.com (Nathan Fritz) Date: Fri, 22 May 2009 11:18:12 -0700 Subject: [PubSub] Timestamps on items In-Reply-To: References: Message-ID: <182eea400905221118j1d489017oda7c765037a1b731@mail.gmail.com> On Fri, May 22, 2009 at 10:13 AM, Robin Collier wrote: > Wouldn't it make sense to have a timestamp on an item? When a get items > request is > sent to a persistent node, there is no way to know when the item was > published. I > don't think it is necessary for live events, but I think it should be > included for items > that were published in the past. After all, it is already required to > produce the date > for an event that is denoted as delayed. > You could include the timestamp in your payload if you needed it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robincollier at hotmail.com Fri May 22 14:03:43 2009 From: robincollier at hotmail.com (Robin Collier) Date: Fri, 22 May 2009 15:03:43 -0400 Subject: [PubSub] Timestamps on items In-Reply-To: <182eea400905221118j1d489017oda7c765037a1b731@mail.gmail.com> References: <182eea400905221118j1d489017oda7c765037a1b731@mail.gmail.com> Message-ID: Date: Fri, 22 May 2009 11:18:12 -0700 From: nathanfritz at gmail.com To: pubsub at xmpp.org Subject: Re: [PubSub] Timestamps on items On Fri, May 22, 2009 at 10:13 AM, Robin Collier wrote: Wouldn't it make sense to have a timestamp on an item? When a get items request is sent to a persistent node, there is no way to know when the item was published. I don't think it is necessary for live events, but I think it should be included for items that were published in the past. After all, it is already required to produce the date for an event that is denoted as delayed. > You could include the timestamp in your payload if you needed it. I thought of that, but I discounted it for several reasons: 1) I believe it would be a common requirement for items in a persistent node, therefore many people would be attempting to reproduce the same functionality in their own way. 2) It would potentially force users to come up with custom schemas that simply 'wrap' existing schemas that contain the actual payload. This complicates development and parsing when using known schemas. 3) It isn't payload, it is a property of the publication of the item. If I don't actually have payload, I would now have to include it to get this property. 4) Clients would be inserting time stamps, which will not give consistent times due to lack of clock syncronization. It makes more sense for the server to insert the timestamp. (Which it already has to do anyway to provide the delay information http://xmpp.org/extensions/xep-0060.html#subscriber-subscribe-last) _________________________________________________________________ Internet explorer 8 lets you browse the web faster. http://go.microsoft.com/?linkid=9655582 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xma at gnu.org Sun May 24 23:50:48 2009 From: xma at gnu.org (Xavier Maillard) Date: Mon, 25 May 2009 06:50:48 +0200 Subject: [PubSub] [OT] pubsub mailing list via gmane ? Message-ID: <87prdxrdjr.wl%xma@gnu.org> Hi, I have switched over gmane service in order to follow xmpp mailing lists. I found almost all list there except the pubsub one. Can someone act on this and add it there ? Thank you, Xavier From christophe.romain at process-one.net Mon May 25 01:55:44 2009 From: christophe.romain at process-one.net (Christophe Romain) Date: Mon, 25 May 2009 08:55:44 +0200 Subject: [PubSub] Timestamps on items In-Reply-To: References: Message-ID: <20090525065544.GC3997@localhost> ejabberd stores creation and modification timestamps on items. so you can write your own node plugin that append or include publish timestamp in the payload to follow your needs. From robincollier at hotmail.com Mon May 25 08:47:58 2009 From: robincollier at hotmail.com (Robin Collier) Date: Mon, 25 May 2009 09:47:58 -0400 Subject: [PubSub] Timestamps on items In-Reply-To: <20090525065544.GC3997@localhost> References: <20090525065544.GC3997@localhost> Message-ID: > Date: Mon, 25 May 2009 08:55:44 +0200 > From: christophe.romain at process-one.net > To: pubsub at xmpp.org > Subject: Re: [PubSub] Timestamps on items > > ejabberd stores creation and modification timestamps on items. > so you can write your own node plugin that append or include > publish timestamp in the payload to follow your needs. I don't actually need this at this point, but the issue came up as something we may need in the future. OpenFire also stores the same information, and I suspect any other implementations probably do the same (as I mentioned, it is needed for the delay information). I think this shows that the implementers of the spec all think this is required information, which means it should be in the specification and thus obtained in a consistent manner without the need to customize the server or payload. _________________________________________________________________ Create a cool, new character for your Windows Live? Messenger. http://go.microsoft.com/?linkid=9656621 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stpeter at stpeter.im Tue May 26 10:41:58 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 26 May 2009 09:41:58 -0600 Subject: [PubSub] PubSubHubbub Message-ID: <4A1C0DC6.3030109@stpeter.im> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Of interest: http://www.onlineaspect.com/2009/05/25/the-protocols-powering-the-real-time-web/ Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkocDcYACgkQNL8k5A2w/vzXnQCaAnvZGhgxrikApUQhhkW30u3m djkAoPXcfxGZg+uHJxQ0UJohJVZ6922+ =ZqDf -----END PGP SIGNATURE----- From mwild1 at gmail.com Tue May 26 10:49:59 2009 From: mwild1 at gmail.com (Matthew Wild) Date: Tue, 26 May 2009 16:49:59 +0100 Subject: [PubSub] PubSubHubbub In-Reply-To: <4A1C0DC6.3030109@stpeter.im> References: <4A1C0DC6.3030109@stpeter.im> Message-ID: <4db9cacb0905260849n2ca4537amdd67159143789371@mail.gmail.com> On Tue, May 26, 2009 at 4:41 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Of interest: > > http://www.onlineaspect.com/2009/05/25/the-protocols-powering-the-real-time-web/ > Nice, I missed this. Also of interest is their FAQ where they state their reasons for not going with XMPP: http://moderator.appspot.com/#15/e=43e1a&t=426ac From stpeter at stpeter.im Tue May 26 11:07:49 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 26 May 2009 10:07:49 -0600 Subject: [PubSub] PubSubHubbub In-Reply-To: <4db9cacb0905260849n2ca4537amdd67159143789371@mail.gmail.com> References: <4A1C0DC6.3030109@stpeter.im> <4db9cacb0905260849n2ca4537amdd67159143789371@mail.gmail.com> Message-ID: <4A1C13D5.8040906@stpeter.im> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/26/09 9:49 AM, Matthew Wild wrote: > On Tue, May 26, 2009 at 4:41 PM, Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Of interest: >> >> http://www.onlineaspect.com/2009/05/25/the-protocols-powering-the-real-time-web/ >> > > Nice, I missed this. Also of interest is their FAQ where they state > their reasons for not going with XMPP: > http://moderator.appspot.com/#15/e=43e1a&t=426ac Clearly all those hosting services need to run Prosody. ;-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkocE9UACgkQNL8k5A2w/vyfzQCguIZiJB3Ze6oOS5Vq842Uitdu hoMAoPu6WHSQi2q5lVC5XNAienRqGLjC =Hbw6 -----END PGP SIGNATURE-----