mozilla / activity-stream-storage-prototype Goto Github PK

@kitcambridge @rfk you might find this interesting https://github.com/kennytm/rust-ios-android

After #4 lets us load up the "place actions" API in Firefox for iOS, we'll need to prove that we can effectively call into it. The (hopefully) simplest way to achieve this will be to add coverage of those APIs to the existing Firefox for iOS test suite.

Like #1, but for getting the data back out.

In order to expose an API on different platforms, we need to have an API to expose :-)

In [1] @mhammond proposed recordPlaceAction and queryPlaceAction so they seem like as good a place as any to start. We don't need to bikeshed the API just yet, because we're more interested in the technical details of exposing it for this first prototype.

So, let's implement a basic memory-backed version of recordPlaceAction and queryPlaceAction that can associate an action to a particular URL at a particular time, and then query out the URLs on which a given action was performed, most recent first.

[1] https://docs.google.com/document/d/1g3OzUc38V-t4EXkO9MUOJ4_TmCqSsz9IJPGh0fCcIgg/edit#

Once the API in #3 exists, we'll need to build some sort of shared library that exposes the API and can be loaded by Firefox for iOS.

FYI: The following changes were made to this repository's wiki:

• defacing spam has been removed

• Restricting write access to contributors is strongly encouraged. Please make that change (documentation).

These were made as the result of a recent automated defacement of publically writeable wikis.

Once the API in #3 exists, we'll need to build some sort of shared library that exposes the API and can be loaded by Firefox for Android.

Storing events seems like it'll be simpler than querying, so let's start brainstorming how writing new events might work! Based on @fluffyemily's explorations in https://github.com/fluffyemily/cross-platform-rust/, I'm guessing we'll need to expose a more low-level API in Rust, and wrap that in C++/Java/Swift for Gecko and Fennec to use.

I'm not really fond of the "key is a string" design in this one...it's too easy to mask typos, and using an Event struct might also let us do interesting things like composing multiple events when we build up queries.

// Sets up the SQLite database, attaches to Places, etc.
let store = Store::open(...).expect("Failed to open store");

// Record some metadata for the URL.
store.record("http://example.com", |recorder| {
  // Record page metadata: number of images, videos, etc. We can replace these
  // directly, without storing the previous values: the number of images or
  // videos on the page might change, but the old values aren't interesting.
  // These are linked to rows in `moz_places`.
  //
  // In this sketch, it's possible to just declare the key and value: we'll create
  // it if it doesn't exist, and overload `set()` for different value types:
  // i64, time::Duration, &str, bool. A more structured design might add a
  // `store.define()` API for every event we'd like to record. `define` would
  // return an `Event` struct, which we could pass to `set` instead of the
  // string name.
  let page = recorder.page();
  page.set("images", 4);
  page.set("videos", 14);

  // Record visit metadata: dwell time, time the page was left open in the
  // background, referring search query, and so on. These are linked to rows
  // in `moz_historyvisits`, which also gives us info that Places records like
  // the visit time, referrer, and transition (link, bookmark, typed into
  // awesomebar, etc).
  let visit = recorder.visit();
  visit.set("dwell-time", Duration::minutes(2));
  visit.set("background-time", Duration::seconds(3));
  visit.set("referring-search-query", "lolcats");

  // Record actions for the visit. We can store timestamps and other
  // interesting info automatically.
  visit.action("share", "send-to-device");
  visit.action("play", "#cat-video-1");
  visit.action("pause", "#cat-video-1");

  // Everything in this function happens in a transaction. At the end, the
  // transaction commits.
}).expect("Failed to record metadata");

Once the API from #3 exists, we'll need to figure out how to expose it to Desktop Firefox. I expect there are some existing patterns for doing this from other rust-based Firefox components, but I don't know enough about them to write them down in this bug.

Once #6 is done Desktop Firefox can load the "place actions" API, we'll need to prove that it can be properly called by other code in Firefox. The (hopefully) simplest way to do this will be to have some xpcshell tests that exercise the API and run as part of a normal Firefox test run.

After #5 lets us load up the "place actions" API in Firefox for Android, we'll need to prove that we can effectively call into it. The (hopefully) simplest way to achieve this will be to add coverage of those APIs to the existing Firefox for Android test suite.