So, I’ve gone back to using sandmill.org for all my blogging needs, here:

http://blog.sandmill.org/

Planet Mozilla has already been updated to point there.

That presents a problem in the following scenario: What happens when a user tries out Firefox 3 (e.g., by installing the upcoming beta), goes back to Firefox 2, then upgrades again to Firefox 3 when it is released? That does not seem like a very unlikely scenario, and it will result in any changes since the downgrade to be thrown away upon starting Firefox 3 again.

I’ve been worried about this problem for some time, and have so far advocated that we simply don’t touch bookmarks.html after initial import (see bug 381216). But after discussing it more today with Mike Connor and Seth Spitzer, I no longer think that is going to work. Why? Because allowing bookmarks.html and places.sqlite to diverge after initial import technically solves dataloss, but practically, it doesn’t. One can argue that the user can go back to Firefox 2, manually export, and import into Firefox 3… except for one little detail: most people won’t install in parallel, they will update. That is, if you try the beta, and then you either install Firefox 3 on top, or you wait until major update happens, then you won’t have Firefox 2 installed, and the fact that your bookmarks.html contains your bookmark changes since you ran the beta won’t help you one bit (unless you know how to look for it, but most people won’t).

So we’re damned if we touch bookmarks.html, and we’re damned if we don’t. What else is there? We can attempt to determine if there were any real changes in bookmarks.html (Mike suggested coming up with a simple list of URLs in bookmarks.html and checking if they all are in places.sqlite), but that still leaves the problem of what to do when there are changes.

The first thing that comes to mind is, well, to merge. But I’m not sure that given the short time-frame we can make that a reality. Perhaps we could do some sort of dumbed-down merge, where we simply grab the bookmarks.html tree and stick it into a folder. Or we do that, but only insert bookmarks that don’t already exist in the places db. Overall, though, I don’t like these options.

Alternatively, we could drop the places bookmarks tables and re-import. Since in Firefox 2 you’d be editing the places-exported bookmarks.html, and you can only run one browser at a time on any given profile, by dropping the db and re-importing you wouldn’t lose any Firefox 3 bookmarks changes. You would, however, lose any Firefox 3-specific data, such as item annotations that aren’t exported to bookmarks.html. Still, maybe this option isn’t so bad, specially if we only do something so drastic when there are “real” changes (not just a new favicon or a last-visited timestamp change).

We’ve considered and rejected many other variants of the above, like having an extension to enable bookmarks.html, or only overwriting bookmarks.html if it hasn’t been changed, or changing the behavior for the beta somehow. We’ve even considered shipping an update to Firefox 2 now, to change it in some way that helps us. Every option that I’ve considered so far, frankly, sucks.

So, what do you think we should do?

Can’t you create files like “NTUSER.DAT{3d4e88f1-6a70-11db-b1ba-d64300c9c793}.TMContainer00000000000000000002.regtrans-ms” somewhere other than in my home directory?  How did you ever think that would be a good idea?

Love,
Dan

The conference was fantastic, in my opinion. There is a great deal of excitement around Firefox here, and there is a vibrant (and growing, from what I could tell) extension developer community. About 160-170 people came to the event, which was fully translated to and from Japanese. It was a great experience, and I’d like to congratulate the Mozilla Japan team for their work there!

I had two small demos at the “Debucon” (the conference). I only had 15 minutes, which made it a little challenging, but I talked a little about Places, showed off Steve Won’s tagging prototype, and also a very early bookmarks sync prototype I hacked up by using Rob Sayrer’s sync.js. It wasn’t as polished as I would’ve liked, I think, but it went well enough.

Unfortunately I lost my camera a few months ago when it fell out of my pocket on a plane, but others took photos of the event. There are some by Shaver here (featuring me with the headset!) and by Gen here.

Yesterday, I was able to participate in another event, this time here at Mozilla Japan HQ. IT Media’s Biz.ID organized a group of Japanese bloggers to come and discuss Mozilla and Firefox 3 with us. We prepared a short presentation for them and answered questions. An article about the event is here [Japanese] — very cool (for me) to see “ダン・ミルズさん” [Mr Dan Mills] in an article. It was very interesting to meet them and have a discussion, though I have to say, I’m glad I don’t have any more deadlines for presentations right now… so I can concentrate on my *other* deadlines ;)

Last week the Firefox Companion for Kodak EasyShare Gallery (also known as Fotofox, the name under which it was community-tested) was officially released. As one of my non-places responsibilities involves partner repacks, I played a small role in its launch. And although I didn’t write the extension, it’s very gratifying to see it on Wired’s top 10 list of Firefox extensions! (Right next to an interview with Shaver. Woo!)

Fotofox, I think, is definitely a step in the right direction for us. Having to leave the browser to batch-upload photos to web sites feels very cumbersome to me. Coming into the Firefox world, this was one of the things I really wanted to see improved, and I’m glad to see we are taking action :)

Fotofox doesn’t solve everything, of course, and I’d like to see other photo uploading ideas prototyped. My immediate complaints are a) I want a smaller interface, something I could leave open without it owning half my browser, and b) the ability to resize my photos as they are uploaded (so I can drag and drop photos straight from iPhoto or even my camera). My photo workflow currently involves using a plugin to iPhoto to upload directly to my flickr page, but personally I’d rather queue up the uploads on my browser window.

Next time I upload some photos (which I really ought to do soon, it’s been ages), I’ll experiment with Fotofox. Sadly, I lost my camera on my last trip, it fell out of my pocket on the plane and was never found. So I have nothing recent to put up :(

Poisoned? :-O

Originally uploaded by thunder.

I am highly amused.

Update: One of my friends suggests we send back a cake that reads “Congratulations on getting tabs! Love, 2001″.

Update 2: Yes, I agree that it would be mean to do so :-) And just for the record: Thanks, IE team!

So far the document looks like this. The numbers I got for pageload are from mozilla/tools/performance, but with a different page set (which I can’t give out due to copyright restrictions).

The tests look pretty promising so far. The trend appears to be: places is a little slower when there’s none or very little history data, but is faster and faster the more history there is. And this makes intuitive sense to me, after all we’re using an indexed database which is optimized for these kinds of things.

Still, we have a lot of work ahead of us to pin down all the problem areas, and keep them under control. This is just the beginning.

I’ve been advised to introduce myself by explaining my irc nick, “v_thunder”… so, here goes:
I grew up in Valencia, Venezuela, but came to college in the US. I was a little nervous about meeting my roommate, because of cultural differences, etc. On move-in day, only a couple of hours after meeting each other, a girl form the same dorm comes in the room to introduce herself… Randy (my roommate) said:

“This is Daniel, but the ladies call him the Venezuelan Thunder.”

And so, I decided he was allright :)

There. Now that that is out of the way, I can actually start blogging about FF.