|
|
| Line 38: |
Line 38: |
| ** should we limit to a blessed type of plugin to address hijacking? | | ** should we limit to a blessed type of plugin to address hijacking? |
| ** what data represents a search plugin? and where are the keywords assoicated with it? | | ** what data represents a search plugin? and where are the keywords assoicated with it? |
|
| |
|
| |
| * Digging notes
| |
| ** /profile/search.json
| |
| *** "directories" will have two entries, the default one ("/Applications/Firefox.app/Contents/MacOS/searchplugins") & "/Users/mozilla/Documents/inbox-desktop/test_profiles/searchplugins" in my case) The first has no usefully syncable data, though it does have a lastModifiedTime (this is the lastModifiedTime of the directory, used for cache invalidation --Gavin)
| |
| ** /profile/search.sqlite(DO NOT SYNC) (this is no longer used after bug 699856, replaced by search-metadata.json --Gavin)
| |
| *** engineid column identifies engine xml file, and notably where it came fromt[app] or [profile]
| |
| **** which would map to the directories list in the search.json?
| |
| *** value column identifies order of appearance in dropdown or is a string if a keyword has been added for that engine
| |
| *** name column is either "order" or "used"
| |
| *** the same 'logical' entry may have more than one entry in the db with subtly different values
| |
| ** pref browser.search.selectedEngine represents the currently selected entry, status "user set" is useful
| |
| ** pref browser.search.useDBForOrder i bet that represents ordering (this gets set to true once the user has customized the search engine order, to indicate that we should use the positioning information in search-metadata.json rather than the one in default prefs (browser.search.order.*) --Gavin)
| |
| ** pref browser.search.order.1-3 are hard coded defaults. do not sync
| |
| ** JAR loading code is for mobile, for their default plugin handling
| |
| ** changes frequently dont show up immediate (but get written on close)
| |
| ** getting a 3rd party search thingy
| |
| *** right click on a website search bar (ie youtube) and /profile/searchplugins will be created with an OpenSearch .xml
| |
| *** searchplugins doesn't exist until you create a non-default one
| |
| ** SQLite table: install addon, go to tools -> SQLiteManager -> select db, go
| |
| ** default engines have a hidden value, which afaic, is never applied to custom engines?
| |
|
| |
| * current problems
| |
| ** how do i gracefully slurp the json content?
| |
| ** design pondering
| |
| *** Should this be like tabs and a one-record /client
| |
| *** or breakdown the table's multiple entry, grab the json and make it one record per 3rd party (but what about ordering of defaults?)
| |
| *** treat the table & the json as entirely separate things, essentially two record types? tis not really the sync way and I do not even know if it is feasible
| |
| *** do i extract the values of the json blob and rebuild it on the client, or send the thing over the wire wholesale?
| |
|
| |
|
| == Design & Design Review == | | == Design & Design Review == |