On 2009/07/15, at 15:31, Peter Saint-Andre wrote:
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 wouldn't (didn't) call it pressing, but for those who need to
support legacy IM networks, there is a real need for a decent solution
for roster integration. Using jabber:iq:roster with external gateways
seems fine by me.
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.
I don't need a new protocol actually. I would like to have the ability
to add extra namespaced nodes to each <item>, that would solve all my
pet peeves with roster entries.
So it's not broken IMHO. The part that was a bit broken was fixed with
roster versioning IMHO.
In this thread (as started by kev) we where talking about adding more
XML nodes to each <item>.
Best regards,
