Closed Bug 437133 Opened 16 years ago Closed 16 years ago

Weave should sync whatever Awesome Bar "learns"

Categories

(Cloud Services :: General, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: anant, Assigned: anant)

Details

Attachments

(2 files)

Currently, only the URI, title, tags and time for bookmarks and history are synchronized. The awesome bar relies on more values such as frequency to calculate autocomplete suggestions. The SQL query which I *think* is used by the adaptive autocomplete search is attached.

Weave should sync the fields used in the query (most importantly moz_inputhistory.input, and moz_places.frecency).

If this information is synchronized, the awesome bar experience will be the same across all firefox instances.
Also, the real motivation behind this was to make personal history and bookmarks searchable in the same way as the firefox location bar does, in the Weave web client :)
Hmm, isn't the frecency calculated from the visits asynchronously in the background?  I think that as long as we sync history visits (which we now do), places will calculate frecency correctly.

Input history is something we don't do, and probably should.

Cc'ing dietrich for advice/comments.
Agree 1000% on the c#1 use case, btw.  We should be able to make a web-based awesomebar!
(In reply to comment #2)
> Hmm, isn't the frecency calculated from the visits asynchronously in the
> background?  I think that as long as we sync history visits (which we now do),
> places will calculate frecency correctly.

Well, even if it were calculated behind the scenes, we still have something to benefit from storing it on the server - because then we don't have to calculate it ourselves in the the web client (which is already slow because of all the decryption!)
True, and you would save yourself the trouble from having to reimplement the places frecency algorithm.

The downside is that the frecency number will be a constantly moving target.  Assuming all numbers change, however slightly, between syncs, it will cause weave to generate edit commands for every item on every sync.  Ouch.
Assignee: nobody → avarma
Blocks: 433901
OS: Mac OS X → All
Priority: -- → P2
Hardware: PC → All
Target Milestone: -- → 0.2
bug 437243 is where we're exposing frecency as a property of URI result nodes.

however, as this is targeting 0.2, you can't really wait for Fx3.1, so will probably have to shortcut-it by going through SQL.
Punting this for 0.3.
No longer blocks: 433901
Target Milestone: 0.2 → 0.3
This patch has two parts:

a) Modify the history engine to sync transition types (extracted directly from moz_historyvisits in places.db)

b) Add a new 'InputEngine' that syncs input history (directly to and from moz_inputhistory in places.db)
Assignee: avarma → anarayanan
Status: NEW → ASSIGNED
Attachment #332862 - Flags: review?(thunder)
Comment on attachment 332862 [details] [diff] [review]
Sync stuff needed by the awesome bar

Looks good.  My only comment is to make sure we don't need to close the db, or reopen it if Places does any trickery.
Attachment #332862 - Flags: review?(thunder) → review+
(In reply to comment #9)
> Looks good.  My only comment is to make sure we don't need to close the db, or
> reopen it if Places does any trickery.

mozIStorage should take care of all that.

Checked-in http://hg.mozilla.org/labs/weave/index.cgi/rev/95a78bee2fdb

Let's reopen the bug when we discover that we're not doing it right :)
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Component: Weave → General
Product: Mozilla Labs → Weave
QA Contact: weave → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: