[Standards] Divergence between XEP-0048 and XEP-0223
stpeter at stpeter.im
Sat Jun 5 01:28:34 UTC 2010
You make some very good points. Comments inline.
On 6/4/10 5:55 PM, Florian Zeitz wrote:
> 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.
We might receive more feedback on the pubsub at xmpp.org list, but I'll
poke some folks there about this thread.
>>> 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.
OK, we have agreement on that fairly minor point. This enables me to
modify XEP-0048 to follow the pattern in XEP-0223. I've created a ticket:
>> 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.
Sure, but you and I are power users. Most regular user don't even know
about bookmarking! Now, something like Weave is another story entirely.
>> 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
> 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.
>> 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.
OK, here's the story. :)
Back in the ancient days we just had pubsub. Following the legacy of the
old transports as well as MUC, we thought of pubsub as a separate
component (e.g., pubsub.example.com). Several years later we realized
that it would be cool if everyone's JID could be a virtual pubsub
service so that you wouldn't need to register with an external service
and require all sorts of convoluted discovery mechanisms (XEP-0119). The
original form of this "pubsub-on-a-JID" concept was PEP. You'll notice
that PEP is "personal eventing" -- in fact it was originally designed
for extended presence (a hot concept back then, encompassing things like
geolocation and mood). Now, when you log in and receive my extended
presence data, you only want to receive my last location or mood or
whatever, which is where the idea of "last published item" comes from.
However, I might publish information that doesn't fit the concept of
extended presence -- i.e., you might want to receive not only the last
published item but every item published since you were last online,
every item since a certain datetime, every item since a particular
ItemID, or some other model. Right now we have no good way to handle
those scenarios. In XEP-0222 and XEP-0223 we forced the square peg of
persistent storage into the round hole of PEP, but you can see that we
cut some corners in that effort.
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. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards