On Thu, 26 Feb 2009 01:35:33 +0100 Jiří Zárevúcký <[email protected]> wrote:
> 2009/2/25 Pavel Simerda <[email protected]>: > > 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. > > > > 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. > Ok, I might forget your bullying... and You might try to look again and reconsider, with the rfc3920-1 and also the bis variants (as I will of course do also, but I don't have so much time, you can imagine). I recommend to finish this thread... and start a new one, rather concentrating on the technical points and correct reasoning. > 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. -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
