[Standards-JIG] Historical XEPs

Ian Paterson ian.paterson at clientside.co.uk
Fri Nov 17 19:23:34 UTC 2006


Remko wrote:
> Are we suddenly affraid to make protocols tailored to their goal,  
> with an eye on making it easy to implement for clients

I like building block protocols like PEP. It often takes years until new 
protocols are implemented across most servers. (Commercial server 
developers often have to wait until their marketing departments identify 
significant customer demand). Building block protocols allow new 
protocols to be developed without requiring server developers to 
implement anything at all. XEP-0189 is a good example.

Perhaps the reason we love XEP-0049 is because it is a building block 
protocol. But it is very limited. IMHO we need more powerful tools to 
fuel our creativity. If we had fun with XEP-0049 just think what we can 
do with PEP. ;-)

IMO the benefits of PEP with empty whitelist are very significant. I 
want to be notified if another of my connected resources has changed my 
preferences (if not I will overwrite those changes). Imagine if rosters 
did not offer the notification feature.

IMO as long as XMPP allows multiple resources to connect at the same 
time, then some form of pubsub is the right place for (all?) 
personal/private data storage.

>> Old XML Storage fails when you want to store a list of items (like
>> bookmarks): you cannot easily add/remove one item.

Right now you can't do that with PEP either! It's strictly one node per 
namespace. The Council is going to discuss changing that restriction 
next week.

> dragging in explicit creation of nodes and  
> custom node configurations for PEP (i.e. whitelist nodes) is not much  
> fun for a simple IM client to implement just to get private XML storage.
>   

Yes, I agree. Currently the client can make life easier by prepending 
all its publish stanzas with a whitelist node creation stanza, and 
ignoring the resulting <conflict/> errors (generated for nodes that 
already exist). But although that is easy, it's certainly not elegant.

So we need to allow automatic node creation for any access model? For 
example by defining a new 'access_model' attribute for the <publish/> 
element? If the node already exists then the pubsub server would simply 
ignore the attribute:

<iq from='juliet at capulet.com/balcony' type='set' id='create-bookmarks'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='http://jabber.org/protocol/prefs'
             access_model='whitelist'>
      <item>
        <storage xmlns='storage:bookmarks'>
          <url name='Complete Works of Shakespeare'
               url='http://the-tech.mit.edu/Shakespeare/'/>
        </storage>
      </item>
    </publish>
  </pubsub>
</iq>


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.

- Ian




More information about the Standards mailing list