-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/30/09 11:19 PM, [email protected] wrote: > > >> -----Original Message----- From: [email protected] >> [mailto:[email protected]] On Behalf Of ext Peter Saint-Andre >> Sent: 30 September, 2009 19:36 To: XMPP publish-subscribe and >> personal eventing Cc: [email protected] Subject: Re: [PubSub] >> [Standards] XMPP 0060 other requests. >> > Mads, I'm replying on the [email protected] list. Please send > pubsub-related questions and comments to that list. > > On 9/30/09 3:17 AM, Mads Randstoft wrote: >>>> For the usage of pubsub that we are implementing now I have a >>>> few other requests, beside the meta-data that I have already >>>> put > forward here. >>>> 1) Transient subscriptions (which have been put forward before) >>>> setting an option for subscribe that tells the component to >>>> unsubscribe if it gets an offline/unavailable presence from >>>> client. This ofcause requires presence based delivery but >>>> should > otherwise be simple. > > Yes, we've discussed that on the list and I think we have consensus > to add it. The only open issue is: does this need to be a node option > as well as a subscription option? > >>>> 2) An extension to the roster based access model, where not >>>> only subscription access is controlled, but also publishing > rights. So the >>>> node creator can allow all in group friends to subscribe to > his travel >>>> blog but all in his travel-mates group to publish entries on > this blog. >>>> (or in our case, a single "administrator" bot handles > construction and >>>> surveillance of nodes and allows all in producer107 group to >>>> publish on queue1 and all in worker103 to subscribe to queue1) >>>> instead of manually setting up affiliations between producers, >>>> > consumers and the queue? > > I need to think a bit more about how this would work. > > >> I second proposal about extended access models for publishing. See >> my version of the story in "[PubSub] Proposed new affiliation: >> Publish-only" -thread. To put it short & simple: could there be >> similar access model for both publishers and subscribers?
So the node could be configured to allow entities based on the following criteria: anyone can publish (probably not a good idea, but perhaps useful for a public discussion node of some kind), anyone can publish who shares presence with the node owner, anyone can publish who is in a particular roster group, publishers need to be authorized, and publishers need to be on a whitelist. What we have right now is in essence a whitelist model. I'll work on that today or tomorrow along with the other edits. 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/ iEYEARECAAYFAkrEmqEACgkQNL8k5A2w/vxn9ACgs+x9PjaytgmCNcBuM8XTPCLW LIIAoKxpdc1nP0TQshbyRXAmoIAkGaVP =fBSU -----END PGP SIGNATURE-----
