Re: [PATCH 0/2] obexd: Fix bug in irmc phonebook and prevent to reintroduce it

Hi Luiz,
Am 25.07.2012 16:22, schrieb Luiz Augusto von Dentz:

Hi Harald,

On Wed, Jul 25, 2012 at 10:18 AM, Harald Schmitt [off-list ref] wrote:

quoted

This one is related to that. But I think your proposal should be a
separate patch since it is about the incomming paths from an irmc
client. This one is more about to what irmc converts the incomming paths
to query phonebook-ebook and phonebook-tracker for contacts and call lists.
At the  moment these well known paths in phonebook-*.c are designed to
match 1:1 with pbap spec and they are very similar to irmc, but there
could be a third implementation to query phonebook where this could be
different.

While the backend indeed take an absolute path this doesnt mean we
have to send as absolute path, not to mention it is not compatible
with mimetypes which is what TYPE header describes, even in case of
PBAP it is wrong to send absolute path in SETPATH.

Patch 1/2 only changes the way phonebook_pull is called (with absolute
path). It has nothing changed about the path resolution/interpretation
that is asked from the client. Sorry for my bad explanations.

To avoid this problems we send relative although we do accept
absolute, but to avoid problems with stack interpreting absolute path
as not valid as OBEX spec state we always send relative paths.

In fact irmc implementation at the moment only accepts relative paths
and I did not change this.

quoted

The patch 1/2 fixes irmc to query phonebook implementation for the well
known absolute path. This was changed in pbap.c with the patch you
stated, but forgot to change in irmc.c.
Patch 2/2 just replaces the well-known phonebook paths which
phoenbook-ebook.c and phonebook-tracker.c support with constants.

Im fine with converting to constants, it is more the sending of
absolute path that Im not comfortable because of the potential
interoperability problems it could cause.

I probably used the wrong term "well known" what I meant by well known
are the paths that phonebook-tracker and phonebook-ebook knows that it
should fetch the contacts, etc. and these are absolute paths. It is not
about the "well known" paths from the pbap spec