[Council] some comments about end of meeting

[Peter Saint-Andre]

Ian Paterson wrote:

> Ideally I'd like to see an updated PEP. But *if* that were not an 
> option, I'd adopt the 060 on a JID approach, and *retract* PEP - since 
> if PEP exists that will distract developers from 060 on a JID (some 
> servers would offer 060 and others only PEP - which doesn't help client 
> developers).

Agreed.

> If we were to throw away PEP then I'd like to see all of PEP's "client 
> simplification magic" incorporated into 060 (auto node creation etc).

Yes, those simplifications are very beneficial from the subscriber side.

> That said, I'm conscious that implementations of PEP already exist, and 
> there are none for "060 on a JID". Although Chris and Ralph might be 
> ready to implement "060 on a JID" right now, would the developers of the 
> popular open source and commercial servers complete that work anytime 
> soon? The close integration with presence means that, AFAICT, 
> implementing "060 on a JID" will be much more difficult than simply 
> importing existing 060 code into the core servers. (Has 060 ever been 
> implemented in Erlang?) So "060 on a JID" is probably best left as a 
> recommended future upgrade path for PEP. In which case IMHO we need an 
> appropriately-featured PEP...

If we agree that we eventually want to get to full pubsub on a JID 
(every JID a virtual pubsub service) then I agree we need to figure out 
what the right upgrade path is.

> I'm very strongly against leaving PEP as it is 

I still don't understand how we approved PEP last September, then. Were 
we all simply missing the point?

> because it doesn't offer 
> sufficient *publishing* functionality to be as useful as the *personal* 
> subset of 060 should be. For example, how can we redesign XEP-0189 with 
> PEP as is? (Please stop and think about that now.)

Will look at that before tomorrow's meeting.

> While I'm in violent agreement that PEP is a stepping stone to 060 on a 
> JID, IMHO without "multiple persistent items" PEP does not hit the sweet 
> spot of providing the most useful functionality while eliminating a 
> significant part of the work required to implement the full 060 spec. 

 From the publisher side, the subscriber side, or both? I think it might 
be useful to think about it that way. Everyone seems to agree on the 
subscriber-side simplifications -- it's the publisher-side 
simplifications that are so contentious.

> (And In order to provide the iq:private replacement functionality (POP), 
> developers are going to have to implement "multiple persistent items" 
> anyway.)

Maybe. I'm still pondering some other approaches but they're not fully 
baked yet...

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/council/attachments/20070501/39cb8e72/smime.bin