> To support this feature then first we need to convert the current > feature into returning a dict. And then have this feature using a dict > as input. Is there already a specification/draft of the format of this dict? If not, I would be tempted to use the 27.007 +CPBR/W field names as keys (e.g. index, number, type, text, adnumber, secondtext, sip_uri, etc.)

I'm assuming you would then want to have "aa{ss} Import(void)" to import and array of contact info dicts from all stores, and respectively "void Export(s, aa{ss})" to export one or more contact info dicts to a specified store?

> > > To support this feature then first we need to convert the current > > > feature into returning a dict. And then have this feature using a > dict > > > as input. > > > > Is there already a specification/draft of the format of this dict? If > not, I would be tempted to use the 27.007 +CPBR/W field names as keys > (e.g. index, number, type, text, adnumber, secondtext, sip_uri, etc.) > > there is not. So you need to propose one here. For simplicity, I would propose that both import and export would use an array of dict's with the 27.007 keys: index: type=integer, import=always export=ignored number: type=string, import=always/empty export=optional/empty type: type=integer, import=always export=mandatory text: type=string, import=always/empty export=optional/empty hidden: type=int, import=always, export=optional/default=0 group: type=string, import=if nonempty, export=optional adnumber: type=string, import=if nonempty, export=optional adtype: type=integer, import/export=mandatory if adnumber nonempty secondtext: type=string, import=if nonempty, export=optional email: type=string, import=if nonempty, export=optional sip_uri: type=string, import=if nonempty, export=optional tel_uri: type=string, import=if nonempty, export=optional Either 'text' or 'number' must be nonempty on export. This simple scheme would also necessitate removing the contact merging from the import functionality. Would that be ok? Otherwise the dict would have to contain a list of number structures instead of number/adnumber fields, and merging/unmerging would have to be (re)implemented for both import and export.

no index number. We will never use them. It is either the full phonebook at once or nothing. The write function has to empty out left over entries.

Actually I prefer we use proper Dict field names. We never use anything literally from the specifications in this area. So why start now. Please propose proper human readable names.

To be honest, the more and more I think about this, the more my conclusion is to not support phonebook export. It is a bad idea. It is highly complex and it is not a feature that will be used anyway.

> So the aa{sv} parameter/return value would be of format: > { >   'name'    : string, >   'group'   : string,   // optional, for eg. organization >   'hidden'  : integer,  // boolean value: defaults to 0 >   'numbers' : array of dict { >     'number'   : string, >     'category' : integer >   }, >   'emails' : array of dict { >     'address'  : string, >     'category' : integer >   }, >   'voip_uris' : array of dict { >     'uri'      : string, >     'category' : integer >   }, > } > > category : enum { // like existing "enum phonebook_number_type" >   HOME, MOBILE, FAX, WORK, OTHER > } this feels a bit too complicated for me. I actually don't want to over-design this feature, but it does have to be consistent with our other key names.

To be honest, the more and more I think about this, the more my conclusion is to not support phonebook export. It is a bad idea. It is highly complex and it is not a feature that will be used anyway.

> To support this feature then first we need to convert the current > feature into returning a dict. And then have this feature using a dict > as input. Does this mean that support for writing to the phonebook is expected to be added to the phonebook modem API as part of ofono core functionality?