On Fri, 2012-08-24 at 16:59 +0300, Luiz Augusto von Dentz wrote:
> + array{string} Fields:
> +
> + Item vcard fields, default is all
> + values.
> +
> + Possible values:
> +
> + "VERSION",
> + "FN",
> + "N",
> + "PHOTO",
> + "BDAY",
> + "ADR",
> + "LABEL",
> + "TEL",
> + "EMAIL",
> + "MAILER",
> + "TZ",
> + "GEO",
> + "TITLE",
> + "ROLE",
> + "LOGO",
> + "AGENT",
> + "ORG",
> + "NOTE",
> + "REV",
> + "SOUND",
> + "URL",
> + "UID",
> + "KEY",
> + "NICKNAME",
> + "CATEGORIES",
> + "PROID",
> + "CLASS",
> + "SORT-STRING",
> + "X-IRMC-CALL-DATETIME"
What about selecting the bits which don't have a named property
associated with them? They are reported by ListFilterFields() and thus
seem to be supported.
Should the API spec really specify the full list? IMHO the documentation
should make it clear that the list is not exhaustive - more fields might
be added in future releases of the PBAP standard and obexd, without
changing the obexd API.
In SyncEvolution, I use ListFilterFields() to a) do sanity checks on
user input and to b) build a list of all fields from which the user can
exclude specific fields. Because the field list is not hard-coded, that
will work for fields which are not defined yet.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
