[ContactsAPI] querying summary information

[Ben Kelly]

All,

As part of my work looking at performance issues in the contacts app I've been exploring the possibility of querying summary data from ContactsAPI. The idea here is that there are many common use cases for needing only a few fields for each contact and retrieving all fields can impose a significant overhead penalty on mobile devices.

The API I came up with looks something like this:

var options = {
summarize: ['givenName', 'familyName']
};
var cursor = mozContacts.getAllSummaries(options);
cursor.onsuccess = function(contact) {
// use contact.givenName
// use contact.familyName
// use contact.id
cursor.continue();
};

The returned contact objects are of a new type called nsIDOMContactSummary. This type has read-only properties and an additional "summarized" property indicating which fields have been selected.

Ideally an nsIDOMContactSummary object could not be used with the save() function in order to avoid overwriting a contact with partial data. After talking with Gregor, it sounds like data merging is not something we want to support.

For a proof-of-concept and some initial performance measures see:

https://bugzilla.mozilla.org/show_bug.cgi?id=873873

Thoughts? Good? Bad? Any feedback is appreciated.

Thanks!

Ben

[JOSE MANUEL CANTERA FONSECA]

I believe the current plan for the Contacts API is to enable DataStores
and as a result allow apps to cache whatever data they want for a
particular UI. Thus, it would make unnecessary the summaries approach

best

El 19/05/13 22:55, "Ben Kelly" <bke...@mozilla.com> escribió:

>_______________________________________________
>dev-webapi mailing list
>dev-w...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-webapi
>



________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Ben Kelly]

On May 20, 2013, at 4:54 AM, JOSE MANUEL CANTERA FONSECA <jm...@tid.es> wrote:
> I believe the current plan for the Contacts API is to enable DataStores
> and as a result allow apps to cache whatever data they want for a
> particular UI. Thus, it would make unnecessary the summaries approach

Thanks for the information Jose. I had not seen that anywhere previously. I had also been speaking with Gregor about ContactsAPI and he had not mentioned it to me. (Or I missed it in the firehose of new information the last few weeks.)

Mounir also said something similar in the bug:

> Ben, we hope to have the Contacts API on top of a DataStore [1] and that should move the issue you are trying to fix to the application context instead of the platform one. In other words, applications would be able to arrange their data the way they want so they will be able to optimize things for their use cases.
>
> [1]
> https://bugzilla.mozilla.org/show_bug.cgi?id=871445

These responses do raise some questions for me, though. I'm probably just confused on things, so I thought I would ask here rather than clutter the bug history. Sorry if these are stupid questions, but I just want to make sure I understand:

1) Are we no longer working to improve the core WebAPIs such as ContactsAPI?

2) Are we pursuing a general application caching approach because we believe its technically impossible to make APIs like ContactsAPI performant for common use cases with the IPC-oriented architecture on this hardware?

3) How does this impact the overarching strategic goal of developing standard APIs for mobile? Requiring secondary APIs to effectively use core APIs would seem to reduce their appeal.

4) What makes improvements to ContactsAPI mutually exclusive with the DataStore caching approach? In this case it would seem they could work in concert to further reduce workload on the device.

Like I said, I apologize if these are stupid questions. As someone new to the project I appreciate you taking the time to educate me.

Thanks!

Ben

[Gregor Wagner]

On May 20, 2013, at 6:10 AM, Ben Kelly <bke...@mozilla.com> wrote:

> On May 20, 2013, at 4:54 AM, JOSE MANUEL CANTERA FONSECA <jm...@tid.es> wrote:
>> I believe the current plan for the Contacts API is to enable DataStores
>> and as a result allow apps to cache whatever data they want for a
>> particular UI. Thus, it would make unnecessary the summaries approach
>
> Thanks for the information Jose. I had not seen that anywhere previously. I had also been speaking with Gregor about ContactsAPI and he had not mentioned it to me. (Or I missed it in the firehose of new information the last few weeks.)

We encountered some bottlenecks that might only be solvable if we move more logic to the app. We still have to see if this is a viable way and if it solves all our problems.
I am more concerned that moving more logic to the app without solving the localized sorting problem won't help us much.
We also can't just ignore the problem of retrieving all contacts with the new approach because it's totally fine if apps don't want to store the contacts in their own DB and rely on the getAll method.

We still have to ship at least 2 version with the current implementation. I think incremental improvements are fine but we shouldn't make huge changes to the API right now.

-Gregor

[Jonas Sicking]

On May 20, 2013 6:10 AM, "Ben Kelly" <bke...@mozilla.com> wrote:
>
> On May 20, 2013, at 4:54 AM, JOSE MANUEL CANTERA FONSECA <jm...@tid.es> wrote:
> > I believe the current plan for the Contacts API is to enable DataStores
> > and as a result allow apps to cache whatever data they want for a
> > particular UI. Thus, it would make unnecessary the summaries approach
>
> Thanks for the information Jose. I had not seen that anywhere previously. I had also been speaking with Gregor about ContactsAPI and he had not mentioned it to me. (Or I missed it in the firehose of new information the last few weeks.)
>

> Mounir also said something similar in the bug:
>
> > Ben, we hope to have the Contacts API on top of a DataStore [1] and that should move the issue you are trying to fix to the application context instead of the platform one. In other words, applications would be able to arrange their data the way they want so they will be able to optimize things for their use cases.
> >
> > [1]
> > https://bugzilla.mozilla.org/show_bug.cgi?id=871445
>
> These responses do raise some questions for me, though. I'm probably just confused on things, so I thought I would ask here rather than clutter the bug history. Sorry if these are stupid questions, but I just want to make sure I understand:
>
> 1) Are we no longer working to improve the core WebAPIs such as ContactsAPI?

We definitely should improve the contracts API where we see fit.
However knowing that the current medium/long term plan will fix this
particular issue means that it may not be worth doing through other
mechanisms.

I.e. if we can easily get performance, or other, wins, then we should
by all means do it. But if it's too much work, or if the goal is
simply to create a cleaner API, then it may not be worth it.

> 2) Are we pursuing a general application caching approach because we believe its technically impossible to make APIs like ContactsAPI performant for common use cases with the IPC-oriented architecture on this hardware?

I just don't see how the current approach can be kept application
agnostic while also high performance.

For example I think if we were to really benefit from the proposal in
the beginning of this thread, we should probably have a separate table
in the back-end database that only contains last-name and first-name.
But that's likely to be pretty application specific and other
applications want last-name, first-name and telephone number.

The only solution I've been able to think of is to have applications
either cache data themselves, or have them tell the implementation
exactly which indexes/mini-tables/groupings etc to store.

> 3) How does this impact the overarching strategic goal of developing standard APIs for mobile? Requiring secondary APIs to effectively use core APIs would seem to reduce their appeal.

Creating something that we can standardize is exactly the goal. See
https://wiki.mozilla.org/WebAPI/DataStore#Why_not_use_specific_APIs_for_the_use-cases_like_the_existing_Contacts_and_SMS.2FMMS_APIs.3F

> 4) What makes improvements to ContactsAPI mutually exclusive with the DataStore caching approach? In this case it would seem they could work in concert to further reduce workload on the device.

It's not mutually exclusive. But if we're going to be replacing the
Contacts API largely with the DataStore API, then features added to
the Contacts API will eventually be removed along with the rest of the
Contacts API.

/ Jonas

[Ben Kelly]

First, thank you all for the feedback. I understand now that DataStore is coming and may end up changing our overall architecture.

That being said, it sounds like people are still open to improving ContactsAPI if there is data to back up the changes.

To that end I would like to continue investigating backend improvements in ContactsAPI. I understand that some (or all) may not make sense once DataStore arrives. I'm ok with that. If we don't continue to push on the backend, however, we can't get the data to make the best future decisions.

So I hope people will be understanding if I continue to propose minor tweaks to the ContactsAPI. I will steer clear of app specific changes. (For example, i think this summary addition would benefit a broad class of applications.) It just seems a bit premature to declare backend and API improvements a dead end.

Thanks!

Ben

[Jonas Sicking]

Yup, that sounds great!