On Wed, Nov 26, 2003 at 12:14:41AM -0600, Chris Toshok wrote: > This looks good and should go in. I've been thinking, though, that > LIST_FIELD might not be the best way to represent the im screen names, > since it lock you into 1 set of parameters per list. What I mean is, > EContact won't let you do: > > X-AIM;TYPE=WORK:toshokwork > X-AIM;TYPE=HOME:toshokhome > > Instead you're forced to do: > > X-AIM:toshokwork;toshokhome > > with no metadata per screen name. I attempted to make the changes as we discussed on IRC, but it doesn't appear that any of the current types for the fields support specifying attributes along with the text. Do you (or anyone else) have a proposal for this? Just to provide an overview of our discussion, and my understanding of it, the fields E_CONTACT_IM_AIM, _JABBER, _YAHOO, _MSN, and _ICQ were changed to be MULTI_LIST_FIELDs, and _AIM_HOME_1, _2, etc., _AIM_WORK_1, _2, etc, and so on for each protocol were created, using ATTR_TYPE_STR_FIELD. Since we can have an unlimited number of accounts setup for a particular person, we can't use _HOME_1, etc. directly. As you stated, those are simply for convenience purposes elsewhere. We want to be directly modifying the lists. I could add a new type (ATTR_MULTI_LIST_FIELD?) to handle this, but I want to consult with people here first. Christian -- Christian Hammond <> The GNUpdate Project chipx86 gnupdate org <> http://www.gnupdate.org/ Build a system that even a fool can use and only a fool will want to use it.
Attachment:
pgpsZV4LRXaNI.pgp
Description: PGP signature