On Mon Apr 28 10:26:50 2008, Pedro Melo wrote:
* implement PEP/PIP in jabberd2;
* re-write the private storage system on top of PIP.
Now your private-storage items have a dual life as PIP nodes also.
New clients can keep using the semantics of the original private-
storage-based protocol, but using PIP as transport. Old clients
will keep on working.
Yes, I wondered about this way of implementing '49, too. But what
concerns me is that clients which support both are likely to end up
checking both, and getting the data twice. So I was thinking of
probably leaving them distinct - I'm rather up in the air on this,
though, and it may be that it's early enough to consider signalling
this strategy so that clients could avoid a double-fetch and store.
Plus, you'd have to figure out how the backward mapping happens - how
do multiple PIP nodes within the same namespace figure into this?
What about cases where the XML payload of the PIP item doesn't fall
within the namespace used as the top-level item node name?
I'm also in agreement that there's probably little point in trying to
extend XEP-0049 with notifications et al. Yes, it might remain
simpler than PIP, but it's likely to be almost as complex. Also, PEP
itself, contrary to popular belief, is not yet perfect, and may need
work - any extensions which come out of that work would open up a
feature-gap between it and a newly extended XEP-0049 again, and
repeating that work would be annoying.
Finally, I don't think that PIP and PEP are sufficiently different as
to warrant a distinct protocol-level interface. I don't see a
difference in the functionality required except for the audience
(and, therefore, ACL), whereas I do see cases whereby one might wish
to make private data shared, and vice-versa, in a simple manner.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
