[Standards] Divergence between XEP-0048 and XEP-0223

Peter Saint-Andre stpeter at stpeter.im
Wed Jun 9 15:10:38 UTC 2010


On 6/5/10 9:27 AM, Kevin Smith wrote:
> On Sat, Jun 5, 2010 at 2:28 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>>> c. It seems a bit strange to me for each bookmark to be a separate item,
>>>> because conceptually "my bookmarks" seems to be its own entity (I don't
>>>> think of each bookmark as a separate thing that needs to be handled
>>>> differently).
>>>> However, Section 4 of XEP-0223 disagrees:
>>>>    Each item published to the node is a logically separate instance of
>>>>    the data to be stored. It is the responsibility of the publishing
>>>>    and receiving entities to construct a complete view of all such
>>>>    items, if desired. For example, each bookmark published to a private
>>>>    data node is a separate piece of data, whereas the history of all
>>>>    items published to the node provides a complete list of the user's
>>>>    bookmarks.
> 
>>> Actually this is what spawned my XEP reading. mcepl asked in gajim@ why
>>> it wasn't one bookmark per item. He was writing some bookmark management
>>> script IIRC.
>>> Modifying bookmarks becomes a lot easier if you don't have to download
>>> all of them, modify the XML and upload everything again (even though you
>>> didn't touch most of it).
>>> If you have one bookmark per item you can just modify that specific item.
> 
> Having all the bookmarks in one item makes it difficult to handle
> extensibility sensibly - a client gets the list of bookmarks, builds
> its model of the bookmarks, and that's fine. Then the user adds a new
> bookmark, and any extensions that a previous client has stored get
> removed - it's possible to avoid this, but it makes the client's life
> unnecessarily difficult. If bookmarks are one per item, you can add
> new bookmarks as much as you like without worrying about damaging old
> ones.

True.

>> So: I think we need to reconsider these non-extended-presence scenarios
>> and figure out better ways to handle them. That might necessitate new
>> profiles of PubSub (other than PEP). Yes, it sound kind of messy, but it
>> can't be uglier than what we have in XEPs 222 and 223. ;-)
> 
> I don't think new profiles of PubSub are particularly nasty - forcing
> anything more into XEP-0060 is something to be avoided at all costs,
> but profiles and extensions seem fine.

Some new profiles might require new features in XEP-0060 (as, for
instance, PEP required presence-based delivery and notification
filtering). But we can fight over which features go in which specs.

For the record, I'm quite open to new profiles of pubsub, starting with
a storage profile so that we can clean up XEPs 222 and 223.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100609/2afead09/attachment.bin>


More information about the Standards mailing list