[PATCH] TODO: Add vCard export to SM/ME stores

[PATCH] TODO: Add vCard export to SM/ME stores

[Jaakko Kiviluoto]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

---
 TODO |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/TODO b/TODO
index bf2305b..9dcb43f 100644
--- a/TODO
+++ b/TODO
@@ -496,3 +496,14 @@ Miscellaneous
 
   Priority: Low
   Complexity: C4
+
+- Enable exporting contact information from vCard data to SM and ME stores.
+  Need to implement a robust vCard parser that can extract at least the
+  fields supported by the existing phonebook module.  Functionality should
+  be analoguous to existing import functionality.
+
+  Implements feature request http://bugs.meego.com/show_bug.cgi?id=4476
+
+  Priority: Low
+  Complexity: C1
+  Owner: Jaakko Kiviluoto <jaakko.j.kiviluoto@intel.com>
-- 
1.7.0.4

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH] TODO: Add vCard export to SM/ME stores

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

Hi Jaakko,

>  TODO |   11 +++++++++++
>  1 files changed, 11 insertions(+), 0 deletions(-)
> 
> diff --git a/TODO b/TODO
> index bf2305b..9dcb43f 100644
> --- a/TODO
> +++ b/TODO
> @@ -496,3 +496,14 @@ Miscellaneous
>  
>    Priority: Low
>    Complexity: C4
> +
> +- Enable exporting contact information from vCard data to SM and ME stores.
> +  Need to implement a robust vCard parser that can extract at least the
> +  fields supported by the existing phonebook module.  Functionality should
> +  be analoguous to existing import functionality.

and you will not be able to write a robust vCard parser that we can
safely run as root or with any kind of ofonod privileges. It is just way
too risky from a security point of view.

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.

Regards

Marcel

RE: [PATCH] TODO: Add vCard export to SM/ME stores

[Kiviluoto, Jaakko J]

[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]

> > diff --git a/TODO b/TODO
> > index bf2305b..9dcb43f 100644
> > --- a/TODO
> > +++ b/TODO
> > @@ -496,3 +496,14 @@ Miscellaneous
> >
> >    Priority: Low
> >    Complexity: C4
> > +
> > +- Enable exporting contact information from vCard data to SM and ME
> stores.
> > +  Need to implement a robust vCard parser that can extract at least
> the
> > +  fields supported by the existing phonebook module.  Functionality
> should
> > +  be analoguous to existing import functionality.
> 
> and you will not be able to write a robust vCard parser that we can
> safely run as root or with any kind of ofonod privileges. It is just
> way
> too risky from a security point of view.

Got it. (I do have a parser implementation 95% ready just in case you're willing to try this another time.)

> 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?

Jaakko

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

RE: [PATCH] TODO: Add vCard export to SM/ME stores

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

Hi Jaakko,

> > 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.

> 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?

It would be "aa{sv} Import()" since I want a proper dict with sv and not
just ss. Also "Export(aa{sv})" since it is all or nothing. The export
would delete any other entries in the phonebook.

And let me be pretty clear here. Writing a phonebook to the SIM is still
stupid. It is fully pointless in a modern smartphone. The only reason
why we would be merging such a feature upstream is for weird Chinese
type approval and nothing else.

Any UI designer that thinks exposing this is a good idea, should find
himself/herself a new job ;)

Regards

Marcel

RE: [PATCH] TODO: Add vCard export to SM/ME stores

[Kiviluoto, Jaakko J]

[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]

> > > 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.

Jaakko

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

RE: [PATCH] TODO: Add vCard export to SM/ME stores

[Bastian, Waldo]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

Marcel wrote:
> > diff --git a/TODO b/TODO
> > index bf2305b..9dcb43f 100644
> > --- a/TODO
> > +++ b/TODO
> > @@ -496,3 +496,14 @@ Miscellaneous
> >  
> >    Priority: Low
> >    Complexity: C4
> > +
> > +- Enable exporting contact information from vCard data to SM and ME stores.
> > +  Need to implement a robust vCard parser that can extract at least the
> > +  fields supported by the existing phonebook module.  Functionality should
> > +  be analoguous to existing import functionality.
> 
> and you will not be able to write a robust vCard parser that we can
> safely run as root or with any kind of ofonod privileges. It is just way
> too risky from a security point of view.
> 
> 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?

Cheers,
Waldo

RE: [PATCH] TODO: Add vCard export to SM/ME stores

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

Hi Waldo,

> > 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?

actually no. General writing of the SIM phonebook will not be supported.

However support for allowing to write an ENTIRE phonebook back to the
SIM card (export) might be added. The emphasis here is clearly on fully
replacing an existing SIM phonebook.

It is the complement of the import function to potentially deal with
Chinese type approval. It is not a functionality that should be
considered for general use. The SIM phonebook is still a pointless
concept these days. Any UI designer wanting to expose this in a moden
smartphone needs to go back to the drawing board.

Regards

Marcel

RE: [PATCH] TODO: Add vCard export to SM/ME stores

[Kiviluoto, Jaakko J]

[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]

> > > > 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.

So, any comments on this format? Should I go ahead and re-implement the Import functionality, plus the new Export functionality?

Jaakko

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

RE: [PATCH] TODO: Add vCard export to SM/ME stores

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

Hi Jaako,

> > > 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

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.

> 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

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.

Regards

Marcel

RE: [PATCH] TODO: Add vCard export to SM/ME stores

[Kiviluoto, Jaakko J]

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

> 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.

Well, if we want a generic data structure, I assume it shouldn't be locked to any finite amount of phone numbers (number, adnumber) per contact either?

Thus we should implement merging and I guess at the same time effort also the same number categorization that is implemented witht he current Import() function.

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
}

Notes:
- Phone numbers must have '+' to indicate international type.
- VoIP uri's must have protocol prefix (e.g. 'sip:' or 'tel:')
- Number/address items could also be (si) structs, whichever feels better.

How does that sound?

Jaakko
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

RE: [PATCH] TODO: Add vCard export to SM/ME stores

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

Hi Jaakko,

> > 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.
> 
> Well, if we want a generic data structure, I assume it shouldn't be locked to any finite amount of phone numbers (number, adnumber) per contact either?
> 
> Thus we should implement merging and I guess at the same time effort also the same number categorization that is implemented witht he current Import() function.
> 
> 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.

Regards

Marcel

RE: [PATCH] TODO: Add vCard export to SM/ME stores

[Kiviluoto, Jaakko J]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

> 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.

Ok, got it. Do you have any insight if MeeGo still wants this (http://bugs.meego.com/show_bug.cgi?id=4476)?

If they do, will they need to maintain a separate branch, or do they need to implement it somehow with a separate component?

Jaakko
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

RE: [PATCH] TODO: Add vCard export to SM/ME stores

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]

Hi Jaakko,

> > 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.
> 
> Ok, got it. Do you have any insight if MeeGo still wants this (http://bugs.meego.com/show_bug.cgi?id=4476)?

the requirement comes from wanting to pass the Chinese type approval.
For a general user it makes no sense. This is a 21st century smart phone
and not some feature phone from the 90ties.

That said, I am curious on how Apple can sell the iPhone on the Chinese
market without having support for writing to the SIM phonebook. Nobody
could give me an answer to that so far.

> If they do, will they need to maintain a separate branch, or do they need to implement it somehow with a separate component?

Private branches or a separate components are not allowed. It is either
oFono supports it or it does not. This is actually pretty much a black
or white feature.

Regards

Marcel

Re: [PATCH] TODO: Add vCard export to SM/ME stores

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

Hi Marcel,

2010/11/23 Marcel Holtmann <marcel@holtmann.org>:
>> 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.

I agree, how about a strict subset of the spec, like a dict of name -> number?

> 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.

I tend to agree. However, people seem to really want to have this
export(), so we need to arrive at some reasonable conclusion here.

Cheers,
Aki