handle urn: urls properly in places (for example, don't show them in history) from private emails: At a recent review of site specific prefs, Myk and I were discussing if it would be possible to re-use annotations and Places instead of his own .sqlite db. It made sense on the surface: "save per site settings/preferences as place annotations". But, there might be an issue if Myk also wants to store per site preferences on domains, like *.google.com, for which there is no url for the moz_places table. To work around that, Myk thought he might be able to use urn:site:google.com urls to accomplish this, but we'd have to fix places to not display urn urls. This might be something we want to do for other add-on authors who want to use Places and annotations for their add-on. Dietrich writes: Sounds ok. URNs seem like an acceptable way to handle wildcarding domains or subsets of sites. And yes, I think annotations will be used in this manner (and others unimaginable) by extension authors, and we should be prepared for that.

So, I'm not sure storing site-specific prefs in the annotation service and representing sites as URNs is the best thing to do. My primary concern is that doing this limits how we can represent a site in the future. For example, it would make it harder to add a column identifying the method we use to identify each site (ETLD+1, full hostname, etc.), since that column wouldn't make sense for other URIs. And conceptually, sites are collections of URIs and have never been represented as URIs themselves (although it's possible to represent them with URNs, since it's possible to represent anything with a URN), so they don't quite fit into the conceptual model underpinning places. Finally, on a minor note, the site-specific pref service exposes a much simpler interface than the annotations service, primarily because it uses nsIVariant to abstract away the handling of multiple datatypes, and using the annotations service as the datastore will mean translating nsIVariant-based calls into the appropriate datatype-specific calls, which introduces greater complexity and risk. On the plus side, reusing the annotations service means one fewer database to load on startup and maintain over time. I wonder if it would make sense to continue to store site-specific prefs in separate tables but put those tables into the Places database and have the Places code maintain their schema and handle loading them on startup as it already does for the current Places tables.

based on myk's comments, marking wontfix.

additionally, myk and I don't think using places.sqlite is the right database for this.

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv