2009/7/10 Jiří Zárevúcky <zarevucky.j...@gmail.com> > 2009/7/10 Me Self <wmso...@gmail.com>: > > Roster always stores the subscription state, which is now "none". How > you store the actual request is up to you. That kind of implementation > details do not reflect in the network, so that is not the kind of > stuff the spec can dictate. > > The only think you need to know is that the item is "hidden" to the > user until the subscription is approved or the item is explicitly > added by the user. That's all you need to know to implement it. How > exactly you do it doesn't matter here. >
The example I mentioned about "none + pending in" hiding an item that was previously visible by no action of the roster owner himself shows that the specs assumption of storing requests in the roster shines through all the way to the (bad) user experience. For a newbie like me reading the spec and building a "clean room" implementation of an XMPP server it was very difficult to understand why the spec dictates to hide such a roster item until I got the point that storing requests in the roster was assumed and that this type of implementation cant tell the difference between a roster item added explicitly by the user and a roster item that was added as a sideeffect of receiving a request. All the semantics regarding how the state of pending requests combined with the state of existing roster items affect what the users sees only makes sence if you understand the implementation thats assumed - that why I thought I would be nice if the spec had explained this (not as a requirement but maybe as background knowledge for the somewhat weird requirement to hide items the user put there himself). Personally I chose an implementation that stores requests separately from the roster - and not hide roster items added explicitly by the user. Its not in compliance with spec. I guess I hoped with my initial question that someone would tell me that my interpretation of the spec was wrong and that "none + pending in" should still be visible if the user added the item himself. Kind regards Søren
