Thread (14 messages) 14 messages, 3 authors, 2012-08-28

Re: [PATCH obexd 7/7] client-doc: Update documentation of PhonebookAccess interface

flat view

From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date: 2012-08-28 12:03:30

Hi Patrick,

On Tue, Aug 28, 2012 at 12:33 PM, Patrick Ohly [off-list ref] wrote:
The user of a specific device would have to know that.

SyncEvolution's "exclude fields" logic is based on the assumption that
requesting everything, including the custom bits, will result in
everything the device supports, just like not specifying any filter at
all.
So there is a possibility that we detect what kind of extra bits the
remote stack implements based on vendor id/product id, but I would
like to avoid specific behavior per device. Besides it seems what we
want is all custom bits.
quoted
quoted
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.
If we can discover what the bits mean then yes, but unfortunately this
is hardcoded in the PBAP spec (see page 30), so we are only defining
the one we know the meaning.
It's okay to only document those, but it should still allow the use of
the other things. Otherwise a user of the API would have to patch obexd
to use the extensions.
quoted
quoted
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.
As you can see from the spec this is pretty static so adding a round
trip to discover the list sounds wrong to me,
Hard-coding it in SyncEvolution seems equally wrong to me. If the list
changes, then only obexd needs to be updated, not "obexd +
SyncEvolution".

It's only one round-trip per session. As a tradeoff between performance
and being future-proof I think doing the call is worth it.
Fair enough so Im keeping ListFilterFields with original names to be
direct match to the vcard fields, I hope this is really useful for
someone.

-- 
Luiz Augusto von Dentz
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help