[sugar] Obtaining Buddy objects as contacts are encountered

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 11 May 2007 at 17:24:49 -0400, Dan Williams wrote:
> On Fri, 2007-05-11 at 19:25 +0100, Simon McVittie wrote:
> > The code only seems to have 'nick', which is set to the name you enter
> > when you first switch on a new OLPC. Is your position that there should
> > be separate attributes, 'nick' which you can change, and 'name' which
> > you can't? Is there any design in which this is documented? In the
> > absence of any particular reference, I'd been assuming the code
> > implements the design.
> 
> Yeah, we should do this.  I assume that Vcard supports First/Last name?
> Note that we also get into issues then with ordering/localization,
> because some locales (Hungary, for example) use family name _first_.
> But that's a problem for sugar, really.

vCard supports both FN (Formatted Name = display name, e.g. "Dan
Williams" and N (structured Name fields, e.g. "Williams;Dan;;Mr.;"). The
fields of N include family and given name, rather than first and last
name; there appears to be no way to indicate which comes first in the
locale of the subject of the vCard.

Telepathy's full Contact Info interface is under revision - the one
currently in the spec is far from ideal, but the replacement needs
further discussion - so I'd suggest we add "full-name" to the OLPC buddy
properties interface. We could always replicate one to the other
automatically, at some point.

For Salut, I think we should also add "jid" to the OLPC buddy properties
(it ought to be in contact info, but again, we don't have a good
interface for that), to make it easier to link mesh and server
identities. In my proposed implementation (which I'm still writing!) we
need to use the JID to link identities, because retrieving the public
key takes network round-trips, and it's problematic to have people turn
up and start interacting in a tube before we actually know who they are.

I'll add full-name support as part of my current round of API changes,
if there are no objections.

Are we happy for the child's full name to be public (to anyone who knows
their JID), from a privacy point of view? I realise the answer is
probably "yes", but I feel I should ask...

What's the intended UI for this? I assume we should use the name entered on
first boot to populate both the full name and the nickname, then let the child
change their nickname to something else later?

Once again, if there's any design documentation I should be consulting
on this, please let me know. Otherwise I'll just carry on trying to make
reasonable decisions so we can get something implemented.

	Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net

iD8DBQFGSDjPWSc8zVUw7HYRAp28AKCILl7ZNrskQp+pLZErIkcPpG4N7gCghBZu
L1B9aic+hx5v45zpY+wTCJk=
=Wj2o
-----END PGP SIGNATURE-----