Hi,
On Apr 25, 2008, at 11:11 PM, Kevin Smith wrote:
On Sat, Mar 29, 2008 at 8:44 PM, Pedro Melo <[EMAIL PROTECTED]>
wrote:
The protocol is using private storage. I talked to one of the
authors,
Kevin, that told me that a PEP-powered version will be available
sometime in
the future. Using private storage is not a big problem, except for
the lack
of notification on update.
Yep, but PEP where available is nicer.
Sure, no arguments there.
This protocol will fail for servers that don't support
private storage.
The only workaround (and its not even complete) that I see for
this is if
we relax the second point of the requirements. If we store the full
meta-contact data on all accounts, with a version attribute, then
we only
need one of the accounts with private storage available.
Well, we can also set a 'master' account to look after servers which
don't support a useful storage mechanism yet. This avoids getting out
of sync between accounts, and allows us to cope until servers are
upgraded.
Sure but then you have to deal with different accounts available at
different times, each one with roster modifications.
How would you solve any conflicts? Of course you could ask the
client, but this is getting complex pretty fast.
2. Attribute selection
Each roster item has several "attributes" that a client keeps track:
There are no clear rules on which of these we should use for the
meta-contact in case they differ between each contact.
If the contacts are ordered, you pick the dominant order.
Always? What about presence <show>? Should we pick available over dnd
and away? should the order be used as the second level sort field
after <show>?
For example, if two different contacts inside the same
meta-contact announce different geo-locations,
How is one person going to have two geolocs? :)
Multiple resources.
This is a topic for another thread: for PEP nodes that should be per-
user and not per-resource, how do we signal between resources which
one is the most representative of them.
Right now, we opted to rename all the contacts, but it is
debatable if this
is not a excessive behavior.
That seems overkill, to me.
Well, it helps a lot if you later move to or temporarily have to use
a client without meta-contacts. But see at the end.
This applies to any attribute change: name and groups.
It seems more than overkill for groups - it seems unhelpful.
See at the end. I think you and I have to very different views of
meta-contacts :)
4. meta-contact tag algorithm
The spec does not suggest any method of creating the tag attribute.
Right, I think you can use what you like
If we are willing to loose the order attribute (and I would not
like that,
but I want something that just works), there is a fallback
protocol that
requires only the usual roster to keep meta-contacts. If we assume
that
roster items with the same name + groups (basically, if the tag
algorithm
above yields the same hash for your roster entries) belong to the
same
meta-contact, we can implement meta-contacts without the need of
any extra
storage, just the roster.
It's a clearly inferior solution, but I don't see this is an awful
workaround if people must use such servers - proxying another of your
servers for storage seems a bit cleaner to me.
Certainly, I'd get very irritated very quickly with any client which
automatically renamed and regrouped my contacts for me. It irritates
me enough when clients change my avatar automatically.
.....
Maybe we have different views of meta-contacts.
XEP-0209 seems to me to be written in a way to minimize roster
modifications: you create a layer over your rosters, using the data
in 209 and try not to touch the original roster in any way.
This is one approach, but if this is the goal, then 209 is extremely
poor on meta-data. To prevent roster modification, you need to take
in account the name of the meta-contact, and probably the groups
where each meta-contact should be placed on.
Also without a clear set of rules on the interaction of a meta-roster
and the contacts order within with changing presence <show> and
probably <priority>, you'll never have interoperable implementations
*from the POV of the end-user*: the experience is largely based on
each implementation and not on the protocol used. This has good and
bad sides, but having seen the focus groups at work, I've become very
negative regarding people ability to deal with more than simple stuff.
Another approach is the one used at SAPO for a couple of years now.
Its clearly roster-based, and it modifies the roster a lot. If you
rename a meta-contact, all your contacts inside will get the same
name. If you modify the groups of a meta-contact, all the contacts
are set to the same group.
You can think that this is very invasive of your roster, and yes, I
used to agree with you. Thats why I pushed for 209 in recent builds
of SAPO Msg for Mac, because I placed myself in the shoes of people
that think like that. But after going through that experience, 209
created more problems than it solved. I think it does too little to
really solve the problem, and annoyed a lot of lower tech users.
Going back to think about this, I think our initial approach, of
roster modification, is better for our users: it's simpler to
explain, and when they use a client without meta-contacts, they can
still find their contacts, because they have the same name and are in
the same groups as the meta-contact. Plus, we use a protocol that we
know its available everywhere, jabber:iq:roster and it even plays
well with the recent 0237 roster sequencing XEP.
I will miss the order attribute in 209, but just not enough. I will
keep waiting for a real jabber:iq:roster annotation protocol :).
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
