[Standards] XMPP-IM - presence subscription handling

Jiří Zárevúcký zarevucky.jiri at gmail.com
Thu Feb 26 00:35:33 UTC 2009


2009/2/25 Pavel Simerda <pavlix at pavlix.net>:
> On Wed, 25 Feb 2009 18:14:40 +0100
> Jiří Zárevúcký <zarevucky.jiri at gmail.com> wrote:
>
>> > The user interface may be easily fixed by client developers... and
>> > possibly a very short Best Practice document.
>> >
>>
>> No, it can't, since behavior required for this is explicitly forbidden
>> by the specification. Also, implementing client's capabilities so
>> differently from the actual protocol makes a terrible mess.
>
> Uh?
>
> I'm afraid one of us must be very very mistaken then. As I read the
> spec, it's not forbidden at all, on the contrary. I would like too see
> something that shows I'm wrong.
>

Sorry, you are right in this. I overlooked a part defining it as
subject to configuration.
I still think this can't be done without numerous problem.

For example:

You get an inbound request. You approve, believing that once you click
"Approve", you are both subscribed. This can't be done, since you
still depend on the other side to fulfill it's part of a "contract".
If you wait for the other side to approve first, you are deadlocked if
the other side implements the same behavior.

>> >> As for the problems you described, any
>> >> inconsistency could just be reset to a clean no-subscription state.
>> >> How often could this happen?
>> >
>> > Too often to ignore. You cannot require users to reset it
>> > manually... users don't care about protocols!
>> >
>>
>> Read "Would it be so often for user to be bothered by vanishing of
>> subscription?". I really don't get the difference from current spec in
>> this area.
>
> Vanishing of subscription is unrelated.
>

Then I misunderstood you. What problems with the authority did you mean?

>>
>> >> Then look at the end-user client interface. I find it a bit
>> >> unintuitive.
>> >
>> > Go and file a bug report or feature request to your client's
>> > developer.
>> >
>>
>> I'm my client's developer.
>
> That doesn't prevent you from filing a bug report, does it? Pardon my
> ignorance.
>

Sure. It doesn't. It would still be closed as WONTFIX, since it can't be fixed.

>> >> Also, the mutual subscription round-trips always annoy
>> >> me. You get the request, user approves and sends his request,
>> >> contact needs to approve again.
>> >
>> > This is simply not true.
>> >
>>
>> Yet in practice, this is completely ordinary work-flow.
>>
>
> In practice, it is done, but I believe it is not needed.
>

That's exactly my point.

>> >> This has been considered in the specification
>> >> by allowing preliminary approval, but that just adds need for the
>> >> server to track this,
>> >
>> > Which is very easy...
>> >
>>
>> Yes.
>>
>> >> and there is no way to tell if there is one. I
>> >
>> > One what?
>> >
>>
>> Preliminary approval.
>>
>
> It's not forbidden anywhere AFAIK.
>

I meant that there is no way to figure out, whether the contact
auto-approves my request before I actually send it. That's just a
completely unimportant cosmetic flaw.

>> >> I already stated the benefits.
>> >
>> > I haven't seen any.
>> >
>> >> Cleaner protocol,
>> >
>> > I don't think so.
>> >
>>
>> Now I'm beginning to think you either have a very bad taste or haven't
>> read XMPP-IM at all. No offense intended.
>>
>
> I like my taste...
>
> And I will not be as arrogant as you are... and will just say you
> probably haven't read carefully and invented limitations that are not
> there.
>
> None taken :).
>

If you don't consider writing twice as much code because of protocols
"flexibility", making user interaction unreliable, being a valid
reason, then I'm inventing limitations. Yes.

>> >> simpler implementation
>> >
>> > I don't see the difference.
>> >
>>
>> As I already told, you probably never written any.
>>
>
> You seem to use your arrogance instead of real evidence.
>

Once I have time for changing my code to use protocol no one else
uses, I'll send you a diff. Forgive me, if I consider you being
arrogant in the first place. Even reducing number of possible states
from nine to four IS a simplification. You simply ignore everything
and generalize to "there is no difference".

>> >> and user interface much closer to the
>> >> real-life needs.
>> >
>> > And this is definitely your client's problem.
>> >
>>
>> User interface is always constrained by the underlying protocol's
>> possibilities. That's not really a client's problem, is it?
>
> Your question is based on a premise that I don't believe (namely that
> it applies to this case).
>

My question is purely rhetorical.

>>
>> It would move complication from the current protocol to the extension.
>> It wouldn't just pop up anywhere.
>> The "flexibility", you have been talking about, is completely useless
>> in more than 99% of real world usage. Don't you think it's an
>> unnecessary complication to define it in the core protocol, when it is
>> very simply possible separately?
>>
>
> I will not answer questions that are based on doubtful premises.
>

What premises are that? I'm not aware of them.

>> >> User doesn't really care,
>> >> whether a dictionary sees his presence or not.
>> >
>> > User doesn't really care about protocol details either.
>> >
>>
>> User cares about client. Client can't dictate the community protocol.
>> Thus, user cares about protocol details.
>
> And logical reasoning is locked in the cupboard, right?
>

Right.

>> > I don't want to discourage you to think it through... you probably
>> > have some good ideas...
>> >
>> > But it would be much easier to read and to answer if you distinguish
>> > between UI implementation details and protocol design.
>>
>> How do you implement a remote desktop over SSH?
>>
>
> It's already implemented, see the manual page of SSH and look for X
> Forwarding.
>

Ok, bad example.
All I wanted to say is that client UI is dependent on the underlying
protocol. You can separate it just like that.



More information about the Standards mailing list