[Standards] publish+configure again
stpeter at jabber.org
Fri Mar 30 16:12:06 UTC 2007
Ralph Meijer wrote:
> On Fri, 2007-03-30 at 00:15 +0100, Ian Paterson wrote:
>> Peter Saint-Andre wrote:
>>> IMHO we have rough consensus to accept the publish+configure in PEP
>>> (XEP-0163) as a logical extension of the existing auto-create feature.
>>> We need to define these features more carefully, including pubsub
>>> service discovery <feature/> vars and error handling. We need to
>>> clearly specify the costs, benefits, and hazards of publish+configure.
>> Yes, and Ralph would probably be the best qulaified person to write a
>> section about the disadvantages of excessive use of publish+configure. :-)
> I had a nice conversation with Ian the other day on my views on PEP in
> general. First off, I don't want to come across as the guy that is
> holding everything up. I want to use this message to explain some of my
> I very much like PEP and can't wait for it to be widely deployed. As I
> am also one of the XEP-0060 authors, I view everything in the PEP
> discussion in light of what that means for XEP-0060. Maybe that helps
> explain some of my hesitations for additional changes.
> I had some reservations about the use of Entity Capabilities previously,
> but that changed. When sending some caps, you will be automatically
> subscribed to a node, for the duration of your IM session. It doesn't
> add any protocol. Cool.
> Same for automatic node creation. It seems to be a valid wish to do
> this, provided you have a good default configuration. Like the caps
> thing, it doesn't add protocol. Nice!
I agree that we don't want to add protocol unless necessary. Given the
stated preferences of many/most developers, it is an open question
whether we can achieve the goal of wide PEP deployment without adding
the (discoverable) publish+configure to the PEP subset of XEP-0060. So
IMHO we may need to weigh the desire for protocol hygiene against the
desire for wide deployment. Not always fun things to balance...
> Basically the only thing that has been bugging me is sending along a
> node configuration with a publish request. This does add protocol, and
> makes us need to change XEP-0060, think about error handling, and add
> some more logic to servers. Like Peter says, adding more logic to
> servers is almost never a real show stopper, so I won't go into that.
> I'm also sure we can get around the error handling.
Again, this must be a discoverable feature that will be optional in
XEP-0060 but required in XEP-0163.
> The reason I always look to XEP-0060, too, is that I envision that
> people want more than what PEP provides now, in the future. In some
> other thread there was mention of more access control on what you
> publish. Things like being able to configure your subscription will be
> interesting, too (only send me notifications when my presence is
> 'online' or 'chat').
Yes, (some) people will eventually want all that. So we need to provide
a straightforward upgrade path from the PEP subset to complete (or more
complete) pubsub. And I think we have that with all the discoverable
features in XEP-0060.
> So, I think for Personal Eventing, server implementations will start off
> with PEP as it is now, and gradually add features from XEP-0060. We have
> a lot of discoverable features, so clients can detect what's there.
> At this point I have some additional questions.
> * If we decide to add p+c, will it be required to implement?
In XEP-0163, I think yes. (Same for auto-create.) But totally optional
> * Will the regular node creation flow and configuration still be in PEP?
> * Client authors: would you implement that flow, too?
I can't answer that. :)
> Just like Magnus is saying, I think for most non-private-storage use
> cases for PEP, you would almost never need/want to change the
> configuration of a node after it has been created.
I agree with that sentiment.
> * Client authors: would you send configuration forms every publish
Given that the presence access model is the required default for PEP
servers, I don't think it would be necessary to send the configuration
form for every publish. IMHO the presence access model is pretty
intuitive for users (if someone can see your presence, they can see your
mood/tune/etc.) so there's not much reason to mess with that.
> Actually I think this holds for the private storage case as well, but it
> seems some client authors are afraid that other clients will cause
IMHO things that are private (whitelist access model) will always be
> * Could someone explain this bit for me?
> * If you don't trust the other client, how can you be sure it doesn't
> mess up other things like the roster, your password or misuse the
> nifty remote control support you might have added?
I have to say that this worry continues to puzzle me.
> I hope to find some time to finish up my own implementation of things
> here and have the code speak for itself. But, when the specs have been
> updated and there is indeed rough consensus, I will not veto it. It
> would be nice to hear the opinions of people that have not yet entered
> the discussion yet, though.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards