[Standards] Divergence between XEP-0048 and XEP-0223
stpeter at stpeter.im
Fri Jun 4 22:52:08 UTC 2010
On 2/25/10 8:07 PM, Florian Zeitz wrote:
Hallo, and sorry about the seriously delayed reply.
> I noticed there is a difference between XEP-0048 Example 3 and XEP-0223
> Example 1, which describe exactly the same process if I understand
> Examples in XEP-0223 don't wrap the bookmark in a <storage/> element.
> It has recently been noted by someone in the Gajim's MUC that it would
> be good to store one bookmark per item.
That's the question, isn't it?
> 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
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.
3. keep <storage/> and store all bookmarks in one <item/>
This makes more sense to me nowadays. Here's why:
a. It maps directly to XEP-0048, except now you've got pushes for
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
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
d. Putting everything in one item is more consistent with the last
published item functionality in PEP.
4. something completely different.
I can't think of something completely different, because I think that 1
and 3 are the primary alternatives.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards