On Wed, 25 Feb 2009 18:14:40 +0100 Jiří Zárevúcký <[email protected]> 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. > >> I see it the other way around. IMO the current way is too > >> complicated to fit in the common needs. > > > > I believe it is equally complicated to your proposal but more > > flexible. > > > > From the client perspective, the current variant can work, > > according to the specs: > > > > Client A: [subscribed],[subscribe*] > > Client B: [subscribed*],[subscribe*] > > > > with some roster management stanzas around and A's server > > automatically answering with [subscribed*]. > > > > (Hope I didn't do any mistake here, * denotes a more basic flow > > here, if A's server doesn't respond - some IMO misinterpret the > > <presence type="subscribed"/>, A's client does) > > > > From user's perspective it's: > > > > User A: Add contact B. > > User B: Accept contact A (means to both grant subscription and add, > > of course) > > > > > > Unfortunately, due to some server's not handling <presence > > type="subscribed"/> > > > > This seems perfectly correct and pretty easy to me. > > > > Forbidden and not really a clean solution. Citation needed. > >> 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. > >> >> Yes, I > >> >> agree that immediate effect would be increasing complexity and > >> >> need of additional effort to maintain backward compatibility. > >> >> That would be a tricky task, but I believe that with proper > >> >> interoperability rules, it would be possible to make transition > >> >> relatively painless. I believe that in a long run, such change > >> >> would be a huge improvement. > >> > > >> > You'd need to know if the transition gives or takes. > >> > > >> > >> First compare the protocol interface itself. My approach would > >> simplify new implementations significantly, once it is widely used. > > > > I don't believe it would simplify them significantly. > > > > That's probably because you never tried. > > >> 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. > >> 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. > >> 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. > >> would like a simple work-flow "Request presence sharing" - "Sharing > >> approved, both are subscribed" / "Sharing declined, nobody is > >> subscribed". > > > > This usecase works well with the current specification > > > > Possible, but not really simple. Just thinking a moment about it gives > me a few possible problems. > > >> 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 :). > >> 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. > >> 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). > >> Just a question... did you ever need to have someone's > >> subscription, while he must not have it? > > > > Not yet. > > > >> Or the other way around? > > > > Probably yes. > > > >> Now I'm talking > >> about human contacts. I never needed something like that. There > >> are of course automated services, that don't care about your > >> presence, so it is reasonable not to send any to cut down > >> bandwidth. That could be very easily done via an extension, that > >> would allow discarding unnecessary stanzas at the source server. > > > > That seems unnecessarily complicated to me. > > > > 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. > >> 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? > >> If there is some > >> paranoid user who does, he can use privacy lists. > > > > Argh.... this seems to be overly complicated for me too. > > Only a very little fraction of users would ever think of the > possibility of some dictionary forwarding your presences elsewhere. > That's a ridiculous idea. > > > 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. > > Sure it might be tempting to build a protocol after UI design... but > > does it really bring any advantage? Do you really need to break > > something that works well just to gain no advantage (or advantages > > as yet unknown)? > > > > I stand for my previous arguments. The current subscription handling > is a mess. At the very least, it would probably stop developers from > introducing useless options to the user. > Who does it? For the XMPP everyone. Why? Protocol is built that way. > <= my personal opinion Yes, your personal opinion. Pavel -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
