[Standards] Divergence between XEP-0048 and XEP-0223
florian.zeitz at gmx.de
Sat Jun 5 15:07:24 UTC 2010
-----BEGIN PGP SIGNED MESSAGE-----
On 2010-06-05 03:28, Peter Saint-Andre wrote:
> 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:
>>> 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.
Sure bookmarks from browsers are entirely another story. But (just for
clairty) that is exactly why I bring it up. If this protocol ends up
being used for them it should scale.
>>> 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. ;-)
Actually that doesn't sound messy to me at all.
As I understand it what we need are guidelines as to what features of
PubSub should be implemented to enable certain use-cases.
A set of features is than a profile. A PubSub service (classic or on a
JID) can support a combination of those profiles.
IMHO if we just define a profile that includes the necessary features
for private/personal XML storage (and in the future possibly profiles
that include features necessary for social networking etc.) and refer to
those in the appropriate places/XEPs that should be a good way to enable
developers to easily find out what features they need to implement in
order to fit a certain use-case.
In any case I don't think we want to restrict ourselves to the features
in the PEP profile, that doesn't seem sustainable as other needs develop.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Standards