[Standards] Divergence between XEP-0048 and XEP-0223
florian.zeitz at gmx.de
Fri Jun 4 23:55:15 UTC 2010
-----BEGIN PGP SIGNED MESSAGE-----
On 2010-06-05 00:52, Peter Saint-Andre wrote:
> On 2/25/10 8:07 PM, Florian Zeitz wrote:
> Hallo, and sorry about the seriously delayed reply.
No worries, you're busy enough. I'm actually mostly disappointed that
you're the only one to reply, because I personally don't have any
(strong) opinion on this and therefore would love to learn what
implementers and others think.
>> If you do this, it means that a <storage/> element would be unnecessary
>> overhead. OTOH if you also need to support Private XML Storage it means
>> you'd store quite different things in PubSub and in Private XML Storage.
> True. I thought about this quite a bit while working on XEP-0223 and I
> admit that I fudged it in the spec because we were in a hurry to push it
> out. But I think we need to be clearer about this issue.
>> So, while the XEPs should be harmonized I wonder which way we should go.
> So do I. I'll number your alternatives:
> 1. drop <storage/> and suggest storing one bookmark per <item/>
> 2. keep <storage/> and store one bookmark per <item/>
> I don't see a big difference between 1 and 2, unless you think that
> removing the <storage/> wrapper will explicitly limit us to one bookmark
> per item.
> However, note that in XEP-0048 the <storage/> element can also contain a
> <url/> child to store bookmarks to web pages! So removing the wrapper
> would change the meaning to either conferences or URLs, but not both.
> Those considerations would lead me to prefer 1 over 2.
Seconded, also because I don't see any added value in having a
<storage/> wrapper in this case.
> 3. keep <storage/> and store all bookmarks in one <item/>
> This makes more sense to me nowadays. Here's why:
Personally I think it makes more sense nowadays mostly due to historical
"baggage", I think we might rather want to specify a protocol that might
improve the current situation. Some more reasoning below.
> a. It maps directly to XEP-0048, except now you've got pushes for
> updates etc.
> b. Most people have few bookmarks (URL storage isn't supported in any
> clients that I know of, and even power users have perhaps a dozen rooms
Really? I personally have 9 and I wouldn't exactly say I'm heavily using
bookmarks. Also people have been talking about using this for Weave like
functionality. If someone actually implements that the number of
bookmarks would eventually get a lot larger than that.
> 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
> 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
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
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.
> d. Putting everything in one item is more consistent with the last
> published item functionality in PEP.
That's actually something I never really got. Having multiple items at
one node is a quite useful and powerful concept. While it makes sense
for PEP to only use the last published item I'm under the impression
that other use-cases (don't ask me for examples, my memory is really
bad) artificially restrict themselves to one item per node. I personally
don't think that's something we should further encourage.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Standards