[Council] some comments about end of meeting

[Kevin Smith]

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.

>> 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.

Yes.

>>  (Has 060 ever been implemented in Erlang?)

Yes - afaicr, ejabberd had one of the early implementations.

> 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.

Agreed.

>> 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). I do agree that 60-on-a-jid for full personal  
publishing is something we should work towards as well, and that we  
can use it to address the myriad use cases which you suspect (and I  
do too) could come about because of this.

> 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.

>> 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.


>> 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 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?

/K
-- 
Kevin Smith
Psi XMPP Client Project Leader (http://psi-im.org)