The roads I take...

This has been a long time coming, actually, and recent developments just put the final nail in the coffin.

I am ending all development and support for my "extension"-type add-ons effective immediately.

This affects (daily user numbers according to addons.mozilla.org):

• Jökulsárlón Download Manager (almost 500 daily users, source on hg.m.o)
• KaiRo.at Mandelbrot (roughly 1000 daily users, source on git-public.kairo.at)
• Tahoe Data Manager (slightly over 300 daily users, source on hg.m.o) - this is also a default part of SeaMonkey.

If anyone is interested in taking over development and maintenance of any of those, please let me know and I'm happy to convert their repositories over to github for easier working with them, and and the new developer to their administration on AMO and/or move them over to you completely.

I will leave them listed on AMO for a little while so people who want to take over can take a look, but I will hide them from the site in the near future if nobody is interested.

The reasons for this step are multiple:

For one thing, I just don't have the time for updating their code or improving them. My job is stressful enough that my head is overflowing with Mozilla-related things all the time, and my employer is apparently not willing to give me any relief (in terms of hiring someone to supplement me) that would give me back sanity, so I need to remove some Mozilla- and software-related thing from my non-work time to gain back a little sanity so that I don't burn out.

I am also really sad that apparently nobody finds the time or energy to make decent managing and notification mechanisms available for UI code around the new-style web storage mechanisms like indexedDB, appCache, or ServiceWorkers caching, while we do have quite nice APIs there for long-standing things like cookies. For getting Tahoe Data Manager (which was my most interesting add-on) to work decently, I would have needed decent APIs there as well.

Then, my interest for experimenting with code has moved more and more away from the browser, which keeps changing around me all the time, and towards actual web development, where existing code doesn't get broken all the time and your code is more isolated. As a bonus, I can develop things that run on my (Firefox OS) phone and that I can show other people when I'm somewhere. And even there, I don't get as much time to dig into stuff as I would like to, see above.

And finally, and that's why this culminates right now, I disagree with some pieces of Mozilla's add-on strategies right now, and I don't want to be part of that as an add-on developer.
For one, I think add-on signing is a good idea in principle, but not enabling developers to test their code in any way in the same builds that users get is against everything I learned in terms of quality assurance. Then, requiring developers and other users of unbranded (or early pre-release) builds to turn off security for everything just to use/test one or two unsigned add-ons just feels plainly wrong to me (and don't tell me it can't be done otherwise, as I know there are perfectly good ways to solve this without undermining signing and preserving more safety). And I also fear that, while add-on signing brings a lot of pain to add-on developers and will make us lose some of them and their users, we will not reduce the malware/adware problem in the mid to long term, but rather make it worse, as they will resort to injecting binary DLLs into the Firefox process, which is the primary cause of startup crashes on updates, and I will have more grief in my actual job due to this, next to Firefox losing users that see those crashes.
And on the deprecation of "the permissive add-on model" as they call it in the post, I think that the Firefox UI being written in web (CSS/JS/HTML) or web-like (XUL) technologies and the ability to write add-ons that can use those to do anything in Firefox, including prototyping and inventing new functionality and UI paradigms, is the main thing that sets Firefox apart product-wise from all its competitors. If we take that away, there is no product reason for using Firefox over any other browser, the only reasons will be the philosophy behind Mozilla (which is what I'm signed up for anyhow)and the specific reflection of those in some internals of the browser, like respecting privacy and choice a little bit more than others - but most people consider that details, and it's hard to win them over with those. Don't get me wrong, I think that the WebExtensions API is a great idea (and it would be awesome to standardize some bits of it across browsers), and add-ons being sandboxed by default is long overdue. But we also would need to require less signing and review for add-ons that are confined to the safe APIs provided there, and I think we'd still, with heavy review, signing, and whatnot, need to allow people to go fully into the guts of Firefox, with full permissions, to provide the basis for the really ground-breaking add-ons that set us apart from the rest of the world. Even though almost all of the code of my add-ons ran within their own browser tab, they required a good reach into high-permission areas, which probably the new WebExtensions API will not allow that way. But I also do not even have the time to investigate how I could adapt my add-ons to any of this, so I decided to better pull the plug right now.

So, all in all, I probably have waited too long with this anyhow, mostly because I really like Tahoe Data Manager, but I just can't go on pretending that I will still develop or even maintain those add-ons.

Again, if anyone is interested in taking over, either fully or with a few patches here and there, please contact me and I'll help to make it happen.

(Note that this does not affect my language packs, dictionaries, or themes at this point, I'm continuing to maintain and develop them, at least for now.)

As I mentioned recently, I have picked up on the Data Manager again, and the new version of the add-on has been made public yesterday.

There's not much in this feature-wise, just a small improvement on deleting entries from lists and a possibility to launch certain views directly when calling it (and that also means it has its own caller function now), next to a few more code restructuring changes from the SeaMonkey reviews, so I only bumped the version number to 1.0.3 and nothing higher - yet.

The really large change though is that the add-on now has a public code name. I have been thinking about this for a while and in the end decided to use code names for all my add-on projects that improve Firefox and/or SeaMonkey functionality, and use bodies of water for them - based on my SeaMonkey roots.



The Data Manager's new code name "Tahoe", and old Washo Indian word for "deep water", refers to a lake on the borders of California and Nevada that is known, among other things, for very deep and very clear waters - similar to the deep reach and clear sight in data that this add-on provides.

I've also picked up Download Manager UI work again, though only as an add-on - even though if it's not up on AMO yet because it's not ready enough for this at the moment. Currently, there's only a source repository for it - and it already has the code name "Jökulsárlón", after an Icelandic glacier lagoon that has pieces breaking off the glacier and swimming through it as icebergs on their way to the sea, just like files through the download manager.

While the Download Manager work will not go into SeaMonkey code, the Data Manager work is or will be (patches are up for the current changes) - and the add-on source code is public as well, of course.

In the mean time, have fun using Tahoe Data Manager - built into SeaMonkey 2.1 or as an add-on for Firefox 4!

P.S.: My German-language dictionaries also have new 2.0.2 versions available in variants for Germany, Austria, Switzerland.

After fast JavaScript and Plugin Crash Protection, here's another major improvement that just came to SeaMonkey 2.1 code and will be in the upcoming Beta - and this time, it's a SeaMonkey-specific invention:

Data Manager



I have reported about the add-on and on the features before, but now this idea I started working on four months ago has made one more step and is included by default in SeaMonkey, starting with manual builds from today as well as tomorrow's nightly builds.

Right now, you find it in the Tools menu or by entering "about:data" in the location bar and it's a pure addition to the other managers of the same data for the moment, until it can do everything those can do and we can remove them. There's a lot of work to do until then and the bug report has a long list of dependencies for those work items - help is appreciated there!

Once again, SeaMonkey 2.1 Beta 1 in early October will be the first version we'll ship to a wider audience for testing this feature.

Data Manager 1.0 is available for installation now!

The major change from 0.9 is optimization to get some speed improvements. I also posted this code as the first version of patch in the SeaMonkey integration bug, preliminary review feedback indicates that there are a number of improvements I still can make and need to make before I can land it - and the add-on will profit from that as well, I'll try to keep things in sync as much as reasonable and possible between the in-SeaMonkey and add-on versions.

There's also a few thing where future feature work is needed, see the list at the end of my previous posting.

Still, I hope Data Manager improves the experience for more and more of you in the future!

I've just uploaded version 0.9 of Data Manager to AMO.

That release actually marks a very important milestone: All I wanted to achieve in Data Manager 1.0 is done, this marks feature completeness in that regard!

The changes from 0.8 are reacting to the remaining data changes (form data, content prefs, permissions) and working with the new XPCOM registration in current nightlies. Actually, the only reason this is version 0.9 and not 1.0 is because I'd like a bit more testing before calling it that - feedback is very welcome! Please grab it when you can (it should go out as a public update within the next days) and test it well.

The first screen shot I made as a teaser in my first post is still accurate, but here I have a few more in addition:



As you can see, the Klingons are after my test profile these days - but thanks to the Data Manager, I have everything in tight control.

Of course, 0.9 or 1.0 are not the end of the line for Data Manager development, though, but this version will be submitted for the first patch to the SeaMonkey integration bug. After I have that up, my plans currently include the following next steps for Data Manager:

• Make it possible to directly open a specific domain/tab from other UI.
• Switch the rest of the SeaMonkey UI to call Data Manager, where needed with those hooks, so the other manager can be removed from SeaMonkey.
• Add the ability to add permissions.
• Add a tab for site storage mechanisms.
• More?

I'm planning on doing further development in the add-on and keep it available for Firefox even once it lands in SeaMonkey - which I hope can happen for our next Alpha.

Until that, Please head over to the add-ons site, install Data Manager, and test it well!

I've been talking about Data Manager here before, the central access point to all kinds of data stored within SeaMonkey and Firefox, like Cookies, Content Preferences, Permissions, and Form Data, all within an about:data tab in the browser.

The current 0.7 version allows all the data to actually be managed, but dynamic updates of the UI on data changes are not fully implemented yet.
The actual functionality works and is stable enough for common use in my internal testing.

And now, it's a public add-on for Firefox and SeaMonkey on AMO!

Feel free to download it and play with it, I think it has some potential. In the meantime, I'm working on those dynamic updates of the UI when data changes, and I made some progress today in detecting what actual entries have changed, so that in a next step, I can actually get the UI updated for those. I hope I will make progress on that soon.

Until then, please test the current version of the add-on and tell me what positive and negative experiences you make with it (except for the lack of dynamic updates, which is the only really known issue).

As I've mentioned here before, I have done some work on recreating the VB app from my high school thesis as a XULRunner application - esp. as I could need the coding practice and Mandelbrot set calculation can nicely show off TraceMonkey's speed.

XULRunner apps are cumbersome when it comes to packaging and delivering them to someone else, though, so I decided to "add-on-ize" this application, and I just finished that and submitted it to AMO. It's even nominated for public, but we'll see how that goes.

So, if you want to try it yourself, you can now get KaiRo.at Mandelbrot for Firefox and SeaMonkey!

In theory, it should even work on mobile Firefox, but I have only tested the XULRunner version on my N810, not the add-on version, and it's not really fit well for the UI. So, it's just experimental, but still nice to show off XUL+JS+canvas+TraceMonkey on a mobile device!


In related news, Data Manager is also available in a first version as an add-on on AMO. This version can now show all the data I want it to display for now, but has rough edges and doesn't let you edit or manage anything yet. Because of this raw state, this will not be "public" for now and versions will stay in beta. Still, I wanted to make it available for testing, so it's there.

Feel free to help testing and get Data Manager for Firefox and SeaMonkey!

NB: I wonder if I should rebrand this to "SeaMonkey Data Manager", just for the fun of Firefox people being able to have the same experience as we have with the Firefox Sync confusion.


With all that, my add-on developer panel on AMO now lists 10 add-ons.

One thing that has been bothering me for some time is that while SeaMonkey is a professional, integrated suite, the experience of managing your private data leaves quite a lot room for improvement.

I like pointing people to how easy it is to find the list of Cookies in SeaMonkey (it's right there in the Tools menu), but what people usually get when actually looking at this window is more than just suboptimal: A long list of items. The only thing that's helpful is the fact that there's a search filter.

Also, getting a hold of what a site has stored is way more difficult than it should be, making one go across multiple manager windows. If you are crazy enough to turn on the dialog to ask you every time a site wants to set a cookie and save the "Allow"/"Deny" settings permanently, the list of those grows fairly large as well. And then, there's image and popup blocking, geolocation settings, passwords and whatnot. Oh, and we also don't have a way of finding or managing form data entries (OK, they're not per site, but still data we store).

Last week, after some discussions that mentioned how conservative and backwards we are, I decided I need to march forward with generic innovation in SeaMonkey and do something about that data thing - in the end, more control over your data is fully in line with where Mozilla wants to go and needs to go in my opinion.

So, today, I started to develop an add-on for this, targeted for inclusion in hopefully already SeaMonkey 2.1 - but we'll see. Here's a first teaser screen shot of my work in progress:



The list at the right gives you an overview of all "effective top-level domains" for which you have saved any cookies, permissions, content preferences, or passwords - and a magic "*" one for global things like form data. If you click on any of those, on the right hand side all tabs are enabled that we have info for (cookies and passwords in my example). The tabs list only that data for that domain space (everything below google.com in my example), so it's much easier to find what you want there - and what else the site has stored, through the tabs.

Oh, and it's all in a tab by itself, just like the new Add-ons Manager, and fully in line with the long-term "everything is a tab" strategy of SeaMonkey!

The source is heavily trimmed to only work in current trunk but it's available in my "dataman" repository and best used by cloning or symlinking it into mozilla/extensions and using the build option "--enable-extensions=default,datamon". In theory, it should work in Firefox, though I haven't tested and not made an overlay for a menu entry yet (about:data in the location bar should just work, though).

Note that this is all just one day's work so far, so not too much is working yet - we list domains for all the data, activate the correct tabs, but only the cookie tab has any content, and that is just a bare list. It's a start, though.

I hope this will make a good addition to at least SeaMonkey to enable better management of data for our users!