Re: [PATCH] TODO: Add vCard export to SM/ME stores
Hi Marcel,
2010/11/23 Marcel Holtmann mar...@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
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH] TODO: Add vCard export to SM/ME stores
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. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] TODO: Add vCard export to SM/ME stores
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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] TODO: Add vCard export to SM/ME stores
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
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH] TODO: Add vCard export to SM/ME stores
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. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] TODO: Add vCard export to SM/ME stores
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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] TODO: Add vCard export to SM/ME stores
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. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] TODO: Add vCard export to SM/ME stores
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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] TODO: Add vCard export to SM/ME stores
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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] TODO: Add vCard export to SM/ME stores
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.
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH] TODO: Add vCard export to SM/ME stores
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
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
