[Standards-JIG] Historical XEPs

[Jean-Louis Seguineau]

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?

Jean-Louis

-----Original Message-----
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 
synchronization issues.

PEP does everything XEP-0049 does, and much more.

- Ian

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.