> 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. >> 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. >> 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. >> >> 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. >> 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. >> 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. >> 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. >> simpler implementation > > I don't see the difference. > As I already told, you probably never written any. >> 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? >> 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? >> 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. >> 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? > 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
