On Mon, 2007-05-14 at 11:24 +0100, Simon McVittie wrote: > -----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.
This all sounds good. dan > 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----- > _______________________________________________ > Sugar mailing list > [email protected] > http://mailman.laptop.org/mailman/listinfo/sugar _______________________________________________ Sugar mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/sugar
