[Council] some comments about end of meeting

[Peter Saint-Andre]

Kevin Smith wrote:
> On 1 May 2007, at 23:50, Peter Saint-Andre wrote:
>> 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.
> 
> I'd be inclined to contest the point - it's taken us this long to get to 
> a stage where people are finally deploying PEP, pulling it would be a 
> huge step backwards.

Sorry, I was agreeing with the desire to get to 60-on-a-JID. It could be 
that the PEP-subscribe smarts could be added to 60, in which case [the 
need for] PEP might simply evaporate.

>>> I'm very strongly against leaving PEP as it is
> 
> I don't think we should be extending PEP very far in the 060 direction 
> beyond its original intention of personal eventing (It was originally 
> named the simplified personal pubsub, but was then renamed to make it 
> clear that it deals with eventing, and not the full publish options). 

IIRC, I renamed it because "PEP" is catchy (I had just talked with Rohit 
Khare at a conference and he mentioned how "publish-subscribe" is such a 
boring name and how something with "eventing" in it would be more user 
friendly).

>> I still don't understand how we approved PEP last September, then. 
>> Were we all simply missing the point?
> 
> People's opinions have changed since then - it wasn't that long ago that 
> Ian and I discussed (and agreed) on 189 being outside the scope of PEP 
> and it being a convincing usecase for full 0060. I do, quite firmly, 
> believe that 189 is a full personal publishing use case; in fact, I 
> can't think of very many things which would encourage rapid deployment 
> of 060-on a jid more than e2e requiring it.

See my post to the standards list just now:

http://mail.jabber.org/pipermail/standards/2007-May/015091.html

>>> 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.)
> 
> Well, I think that we shouldn't redesign 189 for PEP as is, and should 
> instead use it as a motivating factor for getting full 60-on-a-jid 
> deployments. My impression was that I'm the member of council who cases 
> least about 60oaj and even I'm firmly in favour of getting it out there 
> so that we can do personal publishing like this. I'm also very 
> interested in this blog  that keeps getting bandied about, and I firmly 
> believe that's a use case for 60oaj and not PEP, as well.

Could be. But I'm still not sure that things like public keys and user 
profile really map to pubsub. However, notifications of changes to such 
data may map to pubsub.

>>> 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.
> 
> Yes, that's quite valid. I was in favour of p&c for simplifying the 
> publisher as well, but even I see that's a dead dog now. 

I'm not sure that the dog is dead, but you may be right. :)

> I hope that 
> (and believe that) the current PEP spec does dramatically simplify the 
> subscribing, and even without p&c simplifies publishing. It's the server 
> guys for whom this is the complicated work but, as Peter says, they're 
> the smart guys solving the hard problems and that's why they're paid the 
> big bucks :)
> 
>>> (And In order to provide the iq:private replacement functionality 
>>> (POP), developers are going to have to implement "multiple persistent 
>>> items" anyway.)
> 
> I'm not sure this is true, is it?

I'm not either. But see my standards@ post regarding public keys, user 
profile, and the like.

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/20070502/87b15ba2/smime.bin