[PubSub] Brussels report
stpeter at stpeter.im
Mon Apr 20 15:47:12 CDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 2/11/09 6:50 AM, Ralph Meijer wrote:
> 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
>>>> 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.
How about "MyNode"? It has that Microsoft or Yahoo! kind of sound. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the PubSub