Are there any news on this?
2009/1/23 Peter Saint-Andre stpe...@stpeter.im:
Kevin Smith wrote:
009/1/23 Jiří Zárevúcký zarevucky.j...@gmail.com:
Really, if this is something that is going to be discussed, then you should
just allow for extra XML namespaces under each item in the roster.
I
Btw, I got one suggestion that would fix merging contacts: Give
contacts a UUID when you make them a meta contact. That UUID could be
shared on the two servers, so the client knows that the contacts from
both accounts form one meta contact.
--
Jonathan
PGP.sig
Description: Signierter
On Fri, Jan 23, 2009 at 11:30 AM, Jonathan Schleifer
js-xmpp-standa...@webkeks.org wrote:
Btw, I got one suggestion that would fix merging contacts: Give contacts a
UUID when you make them a meta contact. That UUID could be shared on the two
servers, so the client knows that the contacts from
Am 23.01.2009 um 12:32 schrieb Kevin Smith:
Brilliant idea - it's almost as if you'd read the XEP.
I'm sure the last time I looked at it it didn't. And IIRC, Gajim
doesn't use a UUID there either. At least I can't remember having seen
one there when I debugged some meta-contact related
Hi,
On Jan 22, 2009, at 9:05 PM, Remko Tronçon wrote:
Thus, I consider the Kopete behaviour rather bad.
I wouldn't call it bad. It's a good enough poor-man's metacontact,
especially in the case where private storage is not available on the
server. However, I do think behavior like this
Hi,
On Jan 22, 2009, at 9:27 PM, Jiří Zárevúcký wrote:
2009/1/22 Matthew Wild mwi...@gmail.com:
I must say I'm inclined to agree with Olivier. Perhaps we are solving
the problem from the wrong angle? Specifically, perhaps we can solve
the need for users to append (Home), (Work), (ICQ) and
On Jan 23, 2009, at 7:02 AM, Yann Leboulanger wrote:
Jiří Zárevúcký a écrit :
2009/1/22 Yann Leboulanger aste...@lagaule.org:
each contact has its own name, there is not a name for the group
of
contacts.
I don't see how it could be usefull to have a name from the
metacontact
group.
I
2009/1/23 Pedro Melo m...@simplicidade.org:
Hi,
On Jan 22, 2009, at 9:27 PM, Jiří Zárevúcký wrote:
2009/1/22 Matthew Wild mwi...@gmail.com:
I must say I'm inclined to agree with Olivier. Perhaps we are solving
the problem from the wrong angle? Specifically, perhaps we can solve
the need
In the Mac version (Leapfrog), we implemented XEP-0209 and used it
internally (friendly customers and those brace enough to use the nightly
builds) but we rolled to the code back to the simpler version.
At the time, delays to retrieve the private storage items would cause
temporary
Jonathan Schleifer a écrit :
Am 23.01.2009 um 12:32 schrieb Kevin Smith:
Brilliant idea - it's almost as if you'd read the XEP.
I'm sure the last time I looked at it it didn't. And IIRC, Gajim doesn't
use a UUID there either. At least I can't remember having seen one there
when I debugged
On Jan 23, 2009, at 12:35 PM, Jiří Zárevúcký wrote:
2009/1/23 Pedro Melo m...@simplicidade.org:
On Jan 22, 2009, at 9:27 PM, Jiří Zárevúcký wrote:
2009/1/22 Matthew Wild mwi...@gmail.com:
I must say I'm inclined to agree with Olivier. Perhaps we are
solving
the problem from the wrong
On Jan 23, 2009, at 12:38 PM, Jiří Zárevúcký wrote:
In the Mac version (Leapfrog), we implemented XEP-0209 and used it
internally (friendly customers and those brace enough to use the
nightly
builds) but we rolled to the code back to the simpler version.
At the time, delays to retrieve the
2009/1/23 Pedro Melo m...@simplicidade.org:
Hi,
On Jan 22, 2009, at 9:27 PM, Jiří Zárevúcký wrote:
2009/1/22 Matthew Wild mwi...@gmail.com:
I must say I'm inclined to agree with Olivier. Perhaps we are solving
the problem from the wrong angle? Specifically, perhaps we can solve
the need
009/1/23 Jiří Zárevúcký zarevucky.j...@gmail.com:
Really, if this is something that is going to be discussed, then you should
just allow for extra XML namespaces under each item in the roster.
I was thinking about this and it really starts to seem to me like the
best idea of this entire
Kevin Smith wrote:
009/1/23 Jiří Zárevúcký zarevucky.j...@gmail.com:
Really, if this is something that is going to be discussed, then you should
just allow for extra XML namespaces under each item in the roster.
I was thinking about this and it really starts to seem to me like the
best idea
Remko Tronçon wrote:
XEP-0209 (Metacontacts) has been Deferred because of inactivity.
I'll take some action on this after FOSDEM.
And you have some more important writing projects to finish, too. ;-)
/psa
I have 2 question about this spec:
1) Why not use user-specified handle (meta-contact name) instead of
some opaque tag?
2) How are these meta-contact data supposed to be scattered across
multiple accounts? I really didn't get this part. (clarification
needed?)
1) Why not use user-specified handle (meta-contact name) instead of
some opaque tag?
Sure, you could do that too (unlness I overlook something, It's been
some time). I'll clarify this.
2) How are these meta-contact data supposed to be scattered across
multiple accounts? I really didn't get
1) Why not use user-specified handle (meta-contact name) instead of
some opaque tag?
Sure, you could do that too (unlness I overlook something, It's been
some time). I'll clarify this.
The value of the 'tag' is used as a non-human readable unique
identifier for a metacontact.
I think it
Jiří Zárevúcký wrote:
1) Why not use user-specified handle (meta-contact name) instead of
some opaque tag?
Sure, you could do that too (unlness I overlook something, It's been
some time). I'll clarify this.
The value of the 'tag' is used as a non-human readable unique
identifier for a
2009/1/22 Yann Leboulanger aste...@lagaule.org:
each contact has its own name, there is not a name for the group of
contacts.
I don't see how it could be usefull to have a name from the metacontact
group.
I think it could be useful in some scenarios.
Example:
cont...@whatever.org - Contact
Le mardi 20 janvier 2009, XMPP Extensions Editor a écrit :
XEP-0209 (Metacontacts) has been Deferred because of inactivity.
Abstract: This document specifies an XMPP protocol extension for defining
metacontacts and grouping member JIDs.
URL: http://www.xmpp.org/extensions/xep-0209.html
If
Olivier Goffart ogoff...@kde.org wrote:
What would be the need of having different name for sub-contacts
inside the same metacontact?
If someone got two XMPP accounts, you might append the server name in
brackets. Or when using transports, you might want to append something
like (ICQ). Or
2009/1/22 Jonathan Schleifer js-xmpp-standa...@webkeks.org:
Olivier Goffart ogoff...@kde.org wrote:
What would be the need of having different name for sub-contacts
inside the same metacontact?
If someone got two XMPP accounts, you might append the server name in
brackets. Or when using
Thus, I consider the Kopete behaviour rather bad.
I wouldn't call it bad. It's a good enough poor-man's metacontact,
especially in the case where private storage is not available on the
server. However, I do think behavior like this should be optional. I
for example have a few contacts with the
Another thing to clarify - how to handle groups? That is.. Union?
Intersection? Should client synchronize them when merging contacts?
Etc..
I think that best approach would be union and synchronizing between
all sub-contacts.
On Thu, Jan 22, 2009 at 9:05 PM, Remko Tronçon re...@el-tramo.be wrote:
Thus, I consider the Kopete behaviour rather bad.
I wouldn't call it bad. It's a good enough poor-man's metacontact,
especially in the case where private storage is not available on the
server. However, I do think
2009/1/22 Matthew Wild mwi...@gmail.com:
I must say I'm inclined to agree with Olivier. Perhaps we are solving
the problem from the wrong angle? Specifically, perhaps we can solve
the need for users to append (Home), (Work), (ICQ) and (MSN)?
I'm not going to object to this XEP, I just can't
Jiří Zárevúcký a écrit :
Another thing to clarify - how to handle groups? That is.. Union?
Intersection? Should client synchronize them when merging contacts?
Etc..
I think that best approach would be union and synchronizing between
all sub-contacts.
In gajim we show contact in the groups of
XEP-0209 (Metacontacts) has been Deferred because of inactivity.
Abstract: This document specifies an XMPP protocol extension for defining
metacontacts and grouping member JIDs.
URL: http://www.xmpp.org/extensions/xep-0209.html
If and when a new revision of this XEP is published, its status
30 matches
Mail list logo
