[Standards-JIG] Historical XEPs
jean-louis.seguineau at laposte.net
Tue Nov 21 20:02:21 UTC 2006
PEP does the same and more, right. It is just more complex.
Anyhow, there must be a better description on how XEP-0049 can be replaced
by PEP, beyond the current XEP-0163 section 12. Private Data Storage. Or an
"application" XEP of PEP, maybe?
Date: Tue, 21 Nov 2006 11:07:15 +0000
From: Ian Paterson <ian.paterson at clientside.co.uk>
Subject: Re: [Standards-JIG] Historical XEPs
To: XMPP Extension Discussion List <standards-jig at jabber.org>
Message-ID: <4562DDE3.2000703 at clientside.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Remko Trongon wrote:
>> But IM is *not* the only application of XMPP, and other applications
>> may use
>> a pure "on demand" pull of information.
> PEP does not prohibit this. Just do not subscribe to the node (or
> rather, do not specify interest in it in your capabilities node), and
> do a PubSub 'get' to your node each time you want the information.
Yes. PEP and XEP-0060 have been deliberately designed to be able to
support either push or pull.
IMO PEP offers the best of both worlds. A node configured for "Pull with
change notifications" is ideal for many of the applications that
XEP-0049 has been used for.
For example, each connected resource that supports a particular
preferences format will pull the preferences before sending first
presence. If the preferences are changed later by another resource then
it will be informed. So it doesn't need to worry about all the difficult
PEP does everything XEP-0049 does, and much more.
Ian Paterson wrote:
> I agree we shouldn't depricate XEP-0049 before PEP server
> implementations are widespread. Even then IMO it will take a long long
> time until the XEP becomes officially "Obsolete". We've all been
> (ab)using that protocol for years, so a lot of code and, more
> importantly, stored data will need to be ported.
More information about the Standards