2009/7/15 Peter Saint-Andre <[email protected]>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/15/09 8:18 AM, Jiří Zárevúcky wrote: >> 2009/7/15 Pedro Melo <[email protected]>: >>> Hi, >>> >>> On 2009/07/15, at 08:36, Kevin Smith wrote: >>> >>>> While we're discussing upgrading roster handling, can I put my request >>>> in for hanging arbitrary xml off the roster entries, please? >>> Thats the only reason I could come up with to justify changing namespaces. >>> And I think that when Joe mentioned "it would give us a chance to define an >>> extensibility model" this is one of the things that would fallback naturally >>> from such model. >>> >>> The question as always is of scope: do we just make jabber:iq:roster a >>> little bit more liberal and use it for rosters from gateways, or do we go >>> the whole nine yards and create a new roster protocol. >>> >>> I think that creating a new protocol for rosters is something that takes >>> time, and the problem of gateway roster would still be messy until then. >>> >>> I say we fix what the known problem is right now, gateway interaction, by >>> allowing the use of jabber:iq:roster and roster versioning with multiple >>> entities. >>> >> >> I'd say we could do both. Fix the pressing problem now, but start >> designing an entirely new protocol. > > What is "the pressing problem"? > >>> I would love to have XML annotations on roster items, it would solve a lot >>> of with meta-contacts, and other uses cases (personal notes on contacts like >>> "remind me to ask kev for an update on his new client ;)", or alarms "when >>> remko logs on, ask him if the client is coming along"). >>> >>> But how to do it would be a big discussion: would it be possible to just >>> define a new PubSub profile and be done with it? >> >> It's possible I guess, but creating a new roster protocol could have >> another advantages. >> >> For example, the current one doesn't communicate the full state. For >> pending-in, you have to listen for presences and client even has to >> guess the state sometimes. >> >> The presence subscription handling using presence stanzas is another >> thing I always considered quite weird. > > Look, folks, this is a major redesign of core XMPP functionality. I > think we need to tread very very carefully here. What *exactly* is truly > broken (as opposed to not aesthetically pleasing)? What problems are you > trying to solve that are not solved with jabber:iq:roster? Etc. > > Peter >
I'm just pointing out my personal opinion. 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.
