Supporting the Android DB backend

[Gian-Carlo Pascutto]

Hi,

so far, we've been building our bookmarks/history/favicon accesses
through an abstract API (BrowserDB) that maps either to Android's
bookmarks/history DB (AndroidDB) or to our own private, local database
(LocalDB).

As far as I understand, Sync doesn't actually use this API, but uses
BrowserProvider (LocalDB) directly to get access to a more extensive
schema than is available on the Android DB.

The disconnect is now hurting us in a few areas, for example Profile
Migration limits itself to what is available in BrowserDB. This causes
the migrated stuff to be duplicated in Sync (who can't detect that its
duplicated). The proposed solution was to let migration give up on
supporting AndroidDB, and import the stuff that Sync needs:
https://bugzilla.mozilla.org/show_bug.cgi?id=716918
(because part of what migration does is to simplify the places schema
into an Android schema, this isn't just a question of swapping out the
DB backend)

Likewise, Sync needs some features in BrowserProvider that were actually
implemented a week ago in the BrowserDB (that it doesn't use):
https://bugzilla.mozilla.org/show_bug.cgi?id=721898

I queried several people about what the plans where, and got some
conflicting answers. So in an attempt to make sure everybody is aligned
here:

a) Do we still want to be able to offer the switch to use AndroidDB over
LocalDB? Or do we commit fully to LocalDB? (making BrowserDB API
somewhat obsolete)

b) If we want to offer AndroidDB, have we thought about how to mix its
limited schema with what Sync actually needs? Questions like that still
seem entirely open here:
https://bugzilla.mozilla.org/show_bug.cgi?id=708005

c) If we want to offer AndroidDB, but import bookmarks/history with more
information into BrowserProvider (either Sync or Migration), how is the
extended data reduced to AndroidDB schema if that is enabled? Another
migration? What about the other way around (bookmarks added in native
browser)?

--
GCP

[Mark Finkle]

On 02/01/2012 09:23 AM, Gian-Carlo Pascutto wrote:

> a) Do we still want to be able to offer the switch to use AndroidDB over
> LocalDB? Or do we commit fully to LocalDB? (making BrowserDB API
> somewhat obsolete)

I don't think we want to move back to using the system Android DBs. I
can see wanting to migrate data from the system DBs, like desktop
migrates from IE or Safari. Performance and query capabilities are other
reasons we may not be able to move back to system DBs. As we tweak
frecency and indexes for queries, it makes moving back harder, if not
impossible.

The ever changing schema of the system BDs make it harder for Fennec to
create a compatibility layer too.

That's my $0.02

[Brad Lassey]

I think there is some value to feeding data back into the system as a whole, for instance so that 3rd party apps can work with it and to reduce the barriers to entry for other browsers. That said, I don't know that those benefits outweigh the costs of keeping up with schema changes and the privacy concerns many people have.

[Kartikaya Gupta]

On 12-02-02 10:39 , Brad Lassey wrote:
> I think there is some value to feeding data back into the system as a whole, for instance so that 3rd party apps can work with it and to reduce the barriers to entry for other browsers. That said, I don't know that those benefits outweigh the costs of keeping up with schema changes and the privacy concerns many people have.

Another option is to expose the data via our own content provider, so
that it is available to 3rd party apps but doesn't require injecting it
into the system DBs. This content provider could be enabled/disabled by
a user-visible setting, allowing them control over whether or not they
want 3rd party apps to access their Firefox data.

This seems to me the "Android" way of doing things, but I have limited
experience in this area and could be wrong.

(Also apparently sending email to
mozilla.dev.pl...@googlegroups.com bounces for me)

kats