2009/7/15 Peter Saint-Andre <[email protected]>: > On 7/15/09 8:53 AM, Jiří Zárevúcky wrote: >> 2009/7/15 Peter Saint-Andre <[email protected]>: >>> On 7/15/09 8:44 AM, Jiří Zárevúcky wrote: >>>> The only objectively >>>> "broken" thing is probably just the fact you can't be sure about the >>>> existence of incoming subscription request (if declined by a different >>>> resource, you have no idea it happened). >>>> >>>> Subjectively, roster (and subscription handling as a whole) was the >>>> single most annoying thing I've implemented so far, including MUC, >>>> data forms, file-transfer, etc. It's my subjective personal opinion, >>>> though, so you can freely ignore it. >>> I never said that the roster+presence functionality is beautiful, >>> simple, or easy to implement -- only that it has worked for 10 years, so >>> I think we need to be very careful about designing something new and >>> backward-incompatible at this stage. >>> >>> Peter >>> >> >> Well, it may be completely different, but I think backwards >> compatibility wouldn't be a problem. By creating a new protocol with >> different namespace, we would essentially be adding a new interface, >> not replacing the new one. Then it's simply a matter of client >> choosing the interface to use for it's session. > > Right. But then clients and servers need to implement two similar but > different protocols for almost exactly the same functionality. Is this > really worth all the time and effort and confusion involved? > > Peter >
That's what we need to find out, isn't it? We probably first need to sum up the additional functionality we'd want in roster management. Arbitrary attached XML is the first and obvious one, which wouldn't even require a new protocol. Are there any other functionalities we may want? Perhaps some more sophisticated handling including JID and group filtering, etc. I think I saw something about some "roster activation" here. What was that about?
