Closed
Bug 437133
Opened 16 years ago
Closed 16 years ago
Weave should sync whatever Awesome Bar "learns"
Categories
(Cloud Services :: General, defect, P2)
Cloud Services
General
Tracking
(Not tracked)
RESOLVED
FIXED
0.3
People
(Reporter: anant, Assigned: anant)
Details
Attachments
(2 files)
1.17 KB,
text/plain
|
Details | |
15.60 KB,
patch
|
hello
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•16 years ago
|
||
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 :)
Comment 2•16 years ago
|
||
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.
Comment 3•16 years ago
|
||
Agree 1000% on the c#1 use case, btw. We should be able to make a web-based awesomebar!
Assignee | ||
Comment 4•16 years ago
|
||
(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!)
Comment 5•16 years ago
|
||
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.
Updated•16 years ago
|
Assignee: nobody → avarma
Updated•16 years ago
|
Comment 6•16 years ago
|
||
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.
Assignee | ||
Comment 8•16 years ago
|
||
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)
Comment 9•16 years ago
|
||
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+
Assignee | ||
Comment 10•16 years ago
|
||
(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
Updated•15 years ago
|
Component: Weave → General
Product: Mozilla Labs → Weave
Updated•15 years ago
|
QA Contact: weave → general
You need to log in
before you can comment on or make changes to this bug.
Description
•