Hello!
For IVI use cases, Mikel and I were discussing how a phone's address
book could be cached intelligently by an IVI head unit. The rough idea
is that first all contacts get pulled without PHOTO data. This data is
used to match the current phone address book with some potentially
cached local data. Then in a second step, the PHOTO data of all contacts
is requested (*). This is all done in the same PBAP session, so the
numbering of contacts is the same in both steps.
The goal is to get the essential data (names, phone numbers) quickly and
then add pictures later on.
There's one problem with the obexd API regarding this: the result of
PullAll does not include any information about the number that each
entry has in the current PBAP session.
For example, in the first step I get:
BEGIN:VCARD
N:John;;Doe
END:VCARD
In the second step I get:
BEGIN:VCARD
PHOTO:...
END:VCARD
There is no guarantee that this entry is for the same contact, is it?
For example, "John Doe" might have been removed in the meantime, to be
replaced by someone else. The API description also makes no guarantees
about the ordering of entries.
One could request additional data in the second step (and perhaps phones
will send it anyway), but doing the matching based on that anew is
expensive.
Would it be acceptable to extend PullAll() semantics? If the caller
gives the name of an existing target directory, obexd could write each
contact into a separate file in that directory, using a <number>.vcf
naming scheme.
Alternatively, the content of each vcard could be extended with a
"X-OBEXD-PBAP-NUMBER:x" where x is the number of that vcard.
(*) If there was a way to request only contacts which have a photo, that
would be used here. Is there something like it? Without it, the entire
address book needs to be read again with a filter that includes PHOTO
data and nothing else.
--
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.
On Thu, 2012-08-23 at 13:59 +0200, Mikel Astiz wrote:
> Hi,
>
> On Thu, Aug 23, 2012 at 1:28 PM, Patrick Ohly <[email protected]> wrote:
> > On Thu, 2012-08-23 at 14:06 +0300, Luiz Augusto von Dentz wrote:
> >> Hi Patrick,
> >>
> >> On Thu, Aug 23, 2012 at 1:15 PM, Patrick Ohly <[email protected]> wrote:
> >> > On Thu, 2012-08-23 at 11:15 +0300, Luiz Augusto von Dentz wrote:
> >> >> On Thu, Aug 23, 2012 at 10:35 AM, Patrick Ohly <[email protected]> wrote:
> >> >> > On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
> >> >> > Even if we wanted to do it that way, it also wouldn't work at the moment
> >> >> > because the PullAll download doesn't include the information that is
> >> >> > necessary to get the full vcard later on. Any comments about my
> >> >> > proposals for fixing this (download into dir and/or add X- prop to
> >> >> > vcards)?
>
> This is a limitation in the PBAP specification, not the API.
Oops. I was assuming (without checking) that the information was
available at the protocol level and just getting thrown away when
returning it to the caller.
That of course renders the entire discussion mute, there's nothing in
obexd that can be done to make the two-step download more efficient.
Thanks for clarifying that.
> >> > I also don't expect it to work reliably, for example when there is a
> >> > "John Doe, Sr." and John Doe, Jr." in the same address book. Phone
> >> > number also isn't unique (might have been added to two different persons
> >> > who are sharing the same address and phone).
> >>
> >> Yep, but that is the general problem isn't it?
> >
> > Right, but that doesn't mean that we have to start using a method that
> > is prone to this problem when there are better alternatives, like using
> > a known contact number in the current session and requesting that
> > directly.
>
> I don't see any problem here. Every single pass (with or without
> photos) would replace the previous cache. So being smart to match
> contacts is just about optimizing the number of writes to the
> database. We don't need to merge any contact at this point.
You are right, the second pass can simply use the same approach as the
first one, with photo data as additional information. My goal was to
optimize the second pass by limiting it to contacts which have photos
and not having to do the matching again.
--
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.
Hi,
On Thu, Aug 23, 2012 at 1:28 PM, Patrick Ohly <[email protected]> wrote:
> On Thu, 2012-08-23 at 14:06 +0300, Luiz Augusto von Dentz wrote:
>> Hi Patrick,
>>
>> On Thu, Aug 23, 2012 at 1:15 PM, Patrick Ohly <[email protected]> wrote:
>> > On Thu, 2012-08-23 at 11:15 +0300, Luiz Augusto von Dentz wrote:
>> >> On Thu, Aug 23, 2012 at 10:35 AM, Patrick Ohly <[email protected]> wrote:
>> >> > On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
>> >> >> When we connect we attempt to
>> >> >> download the full phonebook which is cached for fast lookup but while
>> >> >> ringing we can download the full vcard including the picture.
This would be too slow, adding a noticeable delay to the user.
>> >> > Even if we wanted to do it that way, it also wouldn't work at the moment
>> >> > because the PullAll download doesn't include the information that is
>> >> > necessary to get the full vcard later on. Any comments about my
>> >> > proposals for fixing this (download into dir and/or add X- prop to
>> >> > vcards)?
This is a limitation in the PBAP specification, not the API.
>> >> What about Search + Pull? If you have download the contact already you
>> >> have the name then you search by name, otherwise search by number,
>> >> with the response you can download the vcard with Pull.
>> >
>> > Isn't that very inefficient? One search request for each contact?
>>
>> It is, that why we need to download this info before hand, but since
>> we cannot depend on the contact handle being unique across the
>> sessions
>
> We don't - the two steps would be in the same PBAP session. In the
> future it might even work across sessions, once the Bluetooth consortium
> adds cross-session references (planned for 2013, as far as I know).
The vcard handled are stable within the session, but AFAIK there is no
link between the PullAll result and the vcard handles. Searching
doesn't solve anything because you still need to use PullAll
(individually pulling is too slow), so you still miss the link.
>> > I also don't expect it to work reliably, for example when there is a
>> > "John Doe, Sr." and John Doe, Jr." in the same address book. Phone
>> > number also isn't unique (might have been added to two different persons
>> > who are sharing the same address and phone).
>>
>> Yep, but that is the general problem isn't it?
>
> Right, but that doesn't mean that we have to start using a method that
> is prone to this problem when there are better alternatives, like using
> a known contact number in the current session and requesting that
> directly.
I don't see any problem here. Every single pass (with or without
photos) would replace the previous cache. So being smart to match
contacts is just about optimizing the number of writes to the
database. We don't need to merge any contact at this point.
Cheers,
Mikel
Hi Patrick,
On Thu, Aug 23, 2012 at 2:28 PM, Patrick Ohly <[email protected]> wrote:
> On Thu, 2012-08-23 at 14:06 +0300, Luiz Augusto von Dentz wrote:
>> Hi Patrick,
>>
>> On Thu, Aug 23, 2012 at 1:15 PM, Patrick Ohly <[email protected]> wrote:
>> > On Thu, 2012-08-23 at 11:15 +0300, Luiz Augusto von Dentz wrote:
>> >> On Thu, Aug 23, 2012 at 10:35 AM, Patrick Ohly <[email protected]> wrote:
>> >> > On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
>> >> >> When we connect we attempt to
>> >> >> download the full phonebook which is cached for fast lookup but while
>> >> >> ringing we can download the full vcard including the picture.
>> >> >
>> >> > Even if we wanted to do it that way, it also wouldn't work at the moment
>> >> > because the PullAll download doesn't include the information that is
>> >> > necessary to get the full vcard later on. Any comments about my
>> >> > proposals for fixing this (download into dir and/or add X- prop to
>> >> > vcards)?
>> >>
>> >> What about Search + Pull? If you have download the contact already you
>> >> have the name then you search by name, otherwise search by number,
>> >> with the response you can download the vcard with Pull.
>> >
>> > Isn't that very inefficient? One search request for each contact?
>>
>> It is, that why we need to download this info before hand, but since
>> we cannot depend on the contact handle being unique across the
>> sessions
>
> We don't - the two steps would be in the same PBAP session. In the
> future it might even work across sessions, once the Bluetooth consortium
> adds cross-session references (planned for 2013, as far as I know).
I suppose this will also mean contacts/handle updates will also have
to be supported. Anyway it is not ready now so we can't really depend
on that.
>> > I also don't expect it to work reliably, for example when there is a
>> > "John Doe, Sr." and John Doe, Jr." in the same address book. Phone
>> > number also isn't unique (might have been added to two different persons
>> > who are sharing the same address and phone).
>>
>> Yep, but that is the general problem isn't it?
>
> Right, but that doesn't mean that we have to start using a method that
> is prone to this problem when there are better alternatives, like using
> a known contact number in the current session and requesting that
> directly.
Well it seems that your method is also error prone, because there is
still a chance the contact handle has been invalidated, removed or
something like that which can cause Pull to fail. Anyway when I said
it is the general problem I was referring to number or name mapping to
multiple contacts and that doesn't matter if you resolve then locally
or search first to only then pull with handles found, the fact is you
can find more than one matching regardless of method you use.
--
Luiz Augusto von Dentz
On Thu, 2012-08-23 at 14:06 +0300, Luiz Augusto von Dentz wrote:
> Hi Patrick,
>
> On Thu, Aug 23, 2012 at 1:15 PM, Patrick Ohly <[email protected]> wrote:
> > On Thu, 2012-08-23 at 11:15 +0300, Luiz Augusto von Dentz wrote:
> >> On Thu, Aug 23, 2012 at 10:35 AM, Patrick Ohly <[email protected]> wrote:
> >> > On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
> >> >> When we connect we attempt to
> >> >> download the full phonebook which is cached for fast lookup but while
> >> >> ringing we can download the full vcard including the picture.
> >> >
> >> > Even if we wanted to do it that way, it also wouldn't work at the moment
> >> > because the PullAll download doesn't include the information that is
> >> > necessary to get the full vcard later on. Any comments about my
> >> > proposals for fixing this (download into dir and/or add X- prop to
> >> > vcards)?
> >>
> >> What about Search + Pull? If you have download the contact already you
> >> have the name then you search by name, otherwise search by number,
> >> with the response you can download the vcard with Pull.
> >
> > Isn't that very inefficient? One search request for each contact?
>
> It is, that why we need to download this info before hand, but since
> we cannot depend on the contact handle being unique across the
> sessions
We don't - the two steps would be in the same PBAP session. In the
future it might even work across sessions, once the Bluetooth consortium
adds cross-session references (planned for 2013, as far as I know).
> > I also don't expect it to work reliably, for example when there is a
> > "John Doe, Sr." and John Doe, Jr." in the same address book. Phone
> > number also isn't unique (might have been added to two different persons
> > who are sharing the same address and phone).
>
> Yep, but that is the general problem isn't it?
Right, but that doesn't mean that we have to start using a method that
is prone to this problem when there are better alternatives, like using
a known contact number in the current session and requesting that
directly.
--
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.
Hi Patrick,
On Thu, Aug 23, 2012 at 1:15 PM, Patrick Ohly <[email protected]> wrote:
> On Thu, 2012-08-23 at 11:15 +0300, Luiz Augusto von Dentz wrote:
>> Hi Patrick,
>>
>> On Thu, Aug 23, 2012 at 10:35 AM, Patrick Ohly <[email protected]> wrote:
>> > On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
>> >> Hi Patrick,
>> >>
>> >> On Wed, Aug 22, 2012 at 7:04 PM, Patrick Ohly <[email protected]> wrote:
>> >> > Hello!
>> >> >
>> >> > For IVI use cases, Mikel and I were discussing how a phone's address
>> >> > book could be cached intelligently by an IVI head unit. The rough idea
>> >> > is that first all contacts get pulled without PHOTO data. This data is
>> >> > used to match the current phone address book with some potentially
>> >> > cached local data. Then in a second step, the PHOTO data of all contacts
>> >> > is requested (*). This is all done in the same PBAP session, so the
>> >> > numbering of contacts is the same in both steps.
>> >> >
>> >> > The goal is to get the essential data (names, phone numbers) quickly and
>> >> > then add pictures later on.
>> >>
>> >> I think it is a good idea, but what about to download the full contact
>> >> vcard only when it is to be displayed?
>> >
>> > There are other use cases that depend on having all data locally, for
>> > example merging address books from several different phones into a
>> > single unified address book. Browsing that unified address book is
>> > expected to include photo data, so loading that on demand isn't an
>> > option.
>>
>> How you deal with conflicts such as different pictures, names for the
>> same contact? In theory merging seems to be the right thing to do but
>> if you have used e.g. Nokia N9 it can cause many problems where the
>> same phone number can be found in multiple contacts. What if we got in
>> a situation where the IVI system show 'Joe' but the phone shows "John"
>> with a different picture, I guess this is supposed to be consistent
>> with the phone that is handling the call.
>
> That wasn't mentioned before as a requirement. I guess it could be done
> so that the local cache is used as a first approximation while the phone
> is asked to provide the final answer.
Yep, that is my understanding too and since the phone has to give the
final answer anyway, we might just download the essential things like
name and number the rest is filled on demand, obviously if we already
have done this in a previous session we keep in storage.
>> >> When we connect we attempt to
>> >> download the full phonebook which is cached for fast lookup but while
>> >> ringing we can download the full vcard including the picture.
>> >
>> > Even if we wanted to do it that way, it also wouldn't work at the moment
>> > because the PullAll download doesn't include the information that is
>> > necessary to get the full vcard later on. Any comments about my
>> > proposals for fixing this (download into dir and/or add X- prop to
>> > vcards)?
>>
>> What about Search + Pull? If you have download the contact already you
>> have the name then you search by name, otherwise search by number,
>> with the response you can download the vcard with Pull.
>
> Isn't that very inefficient? One search request for each contact?
It is, that why we need to download this info before hand, but since
we cannot depend on the contact handle being unique across the
sessions I don't see any other option except if we have fetched the
handle in the same session then we can skip Search and Pull directly.
> I also don't expect it to work reliably, for example when there is a
> "John Doe, Sr." and John Doe, Jr." in the same address book. Phone
> number also isn't unique (might have been added to two different persons
> who are sharing the same address and phone).
Yep, but that is the general problem isn't it? When you got a call you
just have the number if it maps to multiple contacts that is something
the user interface has to handle.
--
Luiz Augusto von Dentz
On Thu, 2012-08-23 at 11:15 +0300, Luiz Augusto von Dentz wrote:
> Hi Patrick,
>
> On Thu, Aug 23, 2012 at 10:35 AM, Patrick Ohly <[email protected]> wrote:
> > On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
> >> Hi Patrick,
> >>
> >> On Wed, Aug 22, 2012 at 7:04 PM, Patrick Ohly <[email protected]> wrote:
> >> > Hello!
> >> >
> >> > For IVI use cases, Mikel and I were discussing how a phone's address
> >> > book could be cached intelligently by an IVI head unit. The rough idea
> >> > is that first all contacts get pulled without PHOTO data. This data is
> >> > used to match the current phone address book with some potentially
> >> > cached local data. Then in a second step, the PHOTO data of all contacts
> >> > is requested (*). This is all done in the same PBAP session, so the
> >> > numbering of contacts is the same in both steps.
> >> >
> >> > The goal is to get the essential data (names, phone numbers) quickly and
> >> > then add pictures later on.
> >>
> >> I think it is a good idea, but what about to download the full contact
> >> vcard only when it is to be displayed?
> >
> > There are other use cases that depend on having all data locally, for
> > example merging address books from several different phones into a
> > single unified address book. Browsing that unified address book is
> > expected to include photo data, so loading that on demand isn't an
> > option.
>
> How you deal with conflicts such as different pictures, names for the
> same contact? In theory merging seems to be the right thing to do but
> if you have used e.g. Nokia N9 it can cause many problems where the
> same phone number can be found in multiple contacts. What if we got in
> a situation where the IVI system show 'Joe' but the phone shows "John"
> with a different picture, I guess this is supposed to be consistent
> with the phone that is handling the call.
That wasn't mentioned before as a requirement. I guess it could be done
so that the local cache is used as a first approximation while the phone
is asked to provide the final answer.
> >> When we connect we attempt to
> >> download the full phonebook which is cached for fast lookup but while
> >> ringing we can download the full vcard including the picture.
> >
> > Even if we wanted to do it that way, it also wouldn't work at the moment
> > because the PullAll download doesn't include the information that is
> > necessary to get the full vcard later on. Any comments about my
> > proposals for fixing this (download into dir and/or add X- prop to
> > vcards)?
>
> What about Search + Pull? If you have download the contact already you
> have the name then you search by name, otherwise search by number,
> with the response you can download the vcard with Pull.
Isn't that very inefficient? One search request for each contact?
I also don't expect it to work reliably, for example when there is a
"John Doe, Sr." and John Doe, Jr." in the same address book. Phone
number also isn't unique (might have been added to two different persons
who are sharing the same address and phone).
> Btw, Im changing the PhonebookAccess API so the parameters like order,
> format and filter is passed in the same method call so the client
> doesn't have to call multiple methods for setting those.
Sure, why not.
--
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.
Hi Patrick,
On Thu, Aug 23, 2012 at 10:35 AM, Patrick Ohly <[email protected]> wrote:
> On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
>> Hi Patrick,
>>
>> On Wed, Aug 22, 2012 at 7:04 PM, Patrick Ohly <[email protected]> wrote:
>> > Hello!
>> >
>> > For IVI use cases, Mikel and I were discussing how a phone's address
>> > book could be cached intelligently by an IVI head unit. The rough idea
>> > is that first all contacts get pulled without PHOTO data. This data is
>> > used to match the current phone address book with some potentially
>> > cached local data. Then in a second step, the PHOTO data of all contacts
>> > is requested (*). This is all done in the same PBAP session, so the
>> > numbering of contacts is the same in both steps.
>> >
>> > The goal is to get the essential data (names, phone numbers) quickly and
>> > then add pictures later on.
>>
>> I think it is a good idea, but what about to download the full contact
>> vcard only when it is to be displayed?
>
> There are other use cases that depend on having all data locally, for
> example merging address books from several different phones into a
> single unified address book. Browsing that unified address book is
> expected to include photo data, so loading that on demand isn't an
> option.
How you deal with conflicts such as different pictures, names for the
same contact? In theory merging seems to be the right thing to do but
if you have used e.g. Nokia N9 it can cause many problems where the
same phone number can be found in multiple contacts. What if we got in
a situation where the IVI system show 'Joe' but the phone shows "John"
with a different picture, I guess this is supposed to be consistent
with the phone that is handling the call.
> What you describe is part of the plan, as fallback when the data is not
> (yet) available locally.
>
>> When we connect we attempt to
>> download the full phonebook which is cached for fast lookup but while
>> ringing we can download the full vcard including the picture.
>
> Even if we wanted to do it that way, it also wouldn't work at the moment
> because the PullAll download doesn't include the information that is
> necessary to get the full vcard later on. Any comments about my
> proposals for fixing this (download into dir and/or add X- prop to
> vcards)?
What about Search + Pull? If you have download the contact already you
have the name then you search by name, otherwise search by number,
with the response you can download the vcard with Pull.
Btw, Im changing the PhonebookAccess API so the parameters like order,
format and filter is passed in the same method call so the client
doesn't have to call multiple methods for setting those.
--
Luiz Augusto von Dentz
On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
> Hi Patrick,
>
> On Wed, Aug 22, 2012 at 7:04 PM, Patrick Ohly <[email protected]> wrote:
> > Hello!
> >
> > For IVI use cases, Mikel and I were discussing how a phone's address
> > book could be cached intelligently by an IVI head unit. The rough idea
> > is that first all contacts get pulled without PHOTO data. This data is
> > used to match the current phone address book with some potentially
> > cached local data. Then in a second step, the PHOTO data of all contacts
> > is requested (*). This is all done in the same PBAP session, so the
> > numbering of contacts is the same in both steps.
> >
> > The goal is to get the essential data (names, phone numbers) quickly and
> > then add pictures later on.
>
> I think it is a good idea, but what about to download the full contact
> vcard only when it is to be displayed?
There are other use cases that depend on having all data locally, for
example merging address books from several different phones into a
single unified address book. Browsing that unified address book is
expected to include photo data, so loading that on demand isn't an
option.
What you describe is part of the plan, as fallback when the data is not
(yet) available locally.
> When we connect we attempt to
> download the full phonebook which is cached for fast lookup but while
> ringing we can download the full vcard including the picture.
Even if we wanted to do it that way, it also wouldn't work at the moment
because the PullAll download doesn't include the information that is
necessary to get the full vcard later on. Any comments about my
proposals for fixing this (download into dir and/or add X- prop to
vcards)?
--
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.
Hi Patrick,
On Wed, Aug 22, 2012 at 7:04 PM, Patrick Ohly <[email protected]> wrote:
> Hello!
>
> For IVI use cases, Mikel and I were discussing how a phone's address
> book could be cached intelligently by an IVI head unit. The rough idea
> is that first all contacts get pulled without PHOTO data. This data is
> used to match the current phone address book with some potentially
> cached local data. Then in a second step, the PHOTO data of all contacts
> is requested (*). This is all done in the same PBAP session, so the
> numbering of contacts is the same in both steps.
>
> The goal is to get the essential data (names, phone numbers) quickly and
> then add pictures later on.
I think it is a good idea, but what about to download the full contact
vcard only when it is to be displayed? When we connect we attempt to
download the full phonebook which is cached for fast lookup but while
ringing we can download the full vcard including the picture. A single
vcard should be really fast specially since we are already connected
and should have a session active, in any case this would have to be
done if the contact is not found locally we should stop any ongoing
operation and attempt to search for the phone number.
--
Luiz Augusto von Dentz