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.

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.

Now, how cool is that?

The Firebug team just announced that their 1.5 version is now available from the addons-mozilla.org ("AMO") website - and this version even supports SeaMonkey 2.0 now!

You don't believe it? Look here:

Install Firebug 1.5 in SeaMonkey 2.0

I have already tried and installed it from their website before, and I have it just right in my browser windows now! I haven't tried it yet, but it has a few things that look interesting, I surely will dig into it when I have time, I already heard a lot of praise about this development tool from the Firefox world, and now I can even use it!

So, after Lightning, we have another one of the big Mozilla add-ons work in SeaMonkey 2.0 - I hope that's the real start for a solid success story now.

Once again, this has been enabled by someone from our great SeaMonkey community, in this case Jens Hatlak (InvisibleSmiley), thanks a lot for testing and writing up patches for this. Also a big "thank you" to the Firebug team for taking those patches quite fast and even convincing AMO that our application suite is really supported!

You might already have read about the release of Lightning 1.0 Beta 1 - maybe you even remember my earlier posts about SeaMonkey 2 and Lightning. And now here's the good news, right from the announcement the calendar team made:

You can install Lightning 1.0 Beta 1 from AMO and manage your calendars now directly from within the SeaMonkey Mail & Newsgroups component.

We have been working closely with the calendar team to make Lightning work as well as possible within SeaMonkey, but we're also sure things can be improved further, and any help is appreciated.
Also, both the SeaMonkey and calendar teams appreciate testing of this Beta and reporting bugs, so we can make your calendaring experience with SeaMonkey and Lightning even better in the future!

I've seen a stream of new comments on my older SeaMonkey and Lightning Calendar" post, so I think I should provide you with a bit of an insight of where we are with this now - after all the official SeaMonkey 2.0 Beta 2 announcement mentions Lightning.

The good news is that you actually can install current Lightning 1.0pre nightlies in SeaMonkey 2.0 Beta 2 and above and you will get a lot of calendaring functionality right in your suite install.

The bad news is that not everything works yet, see the open Lightning-SeaMonkey integration bugs for an overview.

The most notable problems are the invitation feature not working and no access to Lightning preferences.

We are working on solution for both of those and more, some work needs to be done in SeaMonkey code, some in Lightning code, but patches are coming up and we hope to have at least our side, hopefully also their side, fixed when we ship release candidates for SeaMonkey 2.0 and even more the release itself.

Note that all the general points I raised in the original blog post on this topic are still true, neither official Lightning releases with SeaMonkey support nor shipping SeaMonkey with this calendering functionality by default are planned right now, it's all about making it possible at all to install Lightning at all and making it work well enough that people can test that combination more thoroughly.

Working towards SeaMonkey 2, we're improving Add-Ons support tremendously, as you might know. This also includes more and better integration with Mozilla's SeaMonkey Add-Ons site.

I was just reminded by a few events that I need to get in closer contact with the "AMO" (addons.mozilla.org) team for making the experience of that service better for our users.

While I'm writing a mail about this, I thought it would be a good idea to become aware of any additional issues that I should bring into that discussion at a later stage (note that not everything might get resolved right away, but AMO folks are willing to help us make our experience better).

So if you know of problems with the SeaMonkey add-ons website that are about its interaction with or application to SeaMonkey specifically, please let me know in comments to this post, I'll forward the problems (ideally you can also provide an already-filed bug about this for tracking).