Hi Patrick, On Tue, Aug 28, 2012 at 12:33 PM, Patrick Ohly <patrick.ohly@xxxxxxxxx> 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. >> > 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. > >> > 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 -- 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
