[Standards-JIG] Re: proto-JEP: Metacontact Storage
jean-louis.seguineau at laposte.net
Fri Feb 24 18:17:13 UTC 2006
Etan, this is certainly a better way to go. But as you said, adding
syntactic information to the group name is kind of worrying.
It would be SO nice if the roster groups were addressable ;) Something like
<item jid='romeo at example.net'
<group jid='montage at example.net'>Friends</group>
Any idea how we could achieve this?
Date: Fri, 24 Feb 2006 11:48:28 -0500 (EST)
From: Etan Reisner <deryni at eden.rutgers.edu>
Subject: Re: [Standards-JIG] Re: proto-JEP: Metacontact Storage
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <Pine.SOL.4.62.0602241126210.12134 at er5.rutgers.edu>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 24 Feb 2006, Remko Troncon wrote:
> Date: Fri, 24 Feb 2006 17:16:04 +0100
> From: Remko Troncon <remko at el-tramo.be>
> Reply-To: Jabber protocol discussion list <standards-jig at jabber.org>
> To: Jabber protocol discussion list <standards-jig at jabber.org>
> List-Id: Jabber protocol discussion list <standards-jig.jabber.org>
> X-Spam-Status: No, hits=0 tagged_above=-50 required=6.31 tests=
> Subject: [Standards-JIG] Re: proto-JEP: Metacontact Storage
>> Could you describe this in more detail? It's not clear to me (1) what
>> the 'account' attribute identifies and (2) what account merging is.
> 'Account merging' means that you show all contacts of all accounts in one
> flat list (like Gaim does, unlike what Psi does).
> Say you have an account on jabber.org and one on gmail.com. If you have a
> user 'stpeter at jabber.org' on one server, and 'stpeter at gmail.com' on the
> you want to put them in one metacontact. This metacontact crosses the
> boundary (the contacts are on different accounts). So, the only way to
> store your metacontacts would be to choose one 'master' account which
> the metacontact data, and with that data the annotation of what other
> the contact belongs to. It's not clean IMO (what if there are 2 masters,
> how to choose the master, ...), but i think there's no other way out.
> My question is: why does a metacontact need a JID ? Shouldn't it just
> group JIDs together in an ordered list ?
Rather than going with a 'parent' or 'master' account/JID would it not
be possible to use something more like tags? That is you simply mark
each JID with a metacontact tag and the client combines all like tagged
roster entries? This would seem to me to help with the one master vs.
multiple master issue. Though I admit I don't know how best to associate
the tags with the roster items. I have an idea but I'll get there in a
I assume the idea is that clients will merge contacts only when they
appear in the same group (this should be documented either way). I
further assume that since group name isn't specified anywhere this
metacontact applies to all groups the set of contacts happen to appear
in together. This seems possibly unfortunate to me, I can certainly see
cases where I want metacontactization only in certain groups. Should
that be allowed for?
I see two options for how to allow for that:
The JEP can be modified to include a group tag in the parent or
child elements, which would seem to solve this issue (though it still
leaves the one master vs. multiple master issue unresolved).
We could use a Nested Roster Groups approach to this problem
instead. That is we define another groupname delimiter and append a
metacontact tag to the end of the group name, so you would get something
like billw at jabber.org in group='Friends^^Bill' and you could even use
nested roster groups along with this to get
group='Friends::College^^Bill'. A system like this would allow for
per-group control of metacontacts much more easily than adding group
names to the current proposal, at least to my mind. Also it simplifies
what the client needs to do above and beyond getting the normal roster,
a client only gets one extra piece of information rather than a
potentially large list of JIDs.
Just my thoughts on the topic.
P.S. I'm not sure how much of a fan I am of adding syntactic information
to roster item group names to begin with, but seeing how it has already
been accepted by some clients and there exists a JEP for it already I
don't think adding a little more is particularly problematic.
More information about the Standards