I had a happy Saturday so remaining crash bugs for features brought in this release did not disturb me much. I could still keep a positive mindset during those grmpf <censored> debugging sessions… Thanks! nspluginwrapper 1.1.0, a snapshot from the development branch, is now available. However, please note that since it is work-in-progress, you will only find source code here and no binary packages. Besides, the download link is at the bottom so that you can read the whole stuff about 1.1.0, a snapshot towards 1.2.0.

Here is a short list of changes since 1.0.0, details to follow:

• Add support for windowless plugins (Flash Player 10 beta 2)
• Add standalone plugins player (nspluginplayer)
• Restart plugins viewer on error (Martin Stransky)

Windowless plugins support. Windowless plugins are now supported in Firefox 3. Only Flash Player 10 beta 2 and a modified DiamondX plugin were tested. There currently is no means to disable windowless plugins but at compile-time through the ALLOW_WINDOWLESS_PLUGINS macro in npw-viewer.c. This can change in the future if there is a need to do so.

Standalone plugins player. nspluginplayer is a new application that enables you to execute a plugin without a browser. This can be useful for Flash presentation or… simply debugging. The player does not emulate the whole NPAPI but enough is implemented to support Flash Player, Acrobat Reader. Well, this is because I only tested those actually.

Usage is very simple: nspluginwrapper embed-args whereby embed-args are the arguments from an <embed> tag. Here are some examples to demonstrate the program.

• Play a Google video:

  $ nspluginplayer style="width:400px; height:326px;" id="VideoPlayback" type="application/x-shockwave-flash" src="http://video.google.com/googleplayer.swf?docId=-7309713943323243972&hl=en-GB" flashvars=""

• Play a Flash game:
  

  $ nspluginplayer src=http://magic.pen.fizzlebot.com/magic-pen.swf width=800 height=520

• View a PDF document:
  

  $ nspluginplayer src=/path/to/some/file.pdf

Auto-restart plugins. The plugins system is now restarted when an error is encountered. This is not fully automatic though. i.e. if a plugin crashed, you have two options to restart it: (i) reload the page, (ii) wait for a refresh requested by the page (through some javascript or whatever triggers an NPP_New() call). You no longer have to restart the browser!

Downloads. nspluginwrapper 1.1.0 is available as source code only. You can get packages from your distributor or build your own. RPMs are really simple to get: rpm -tb nspluginwrapper-1.1.0.tar.bz2 will generate binary RPMs in your usual tree.

What's next? The plan is to get the final nspluginwrapper 1.2.0 within the next 3 months, but I can't predict in what mental state I will be by this time. Another major feature I want for this release is the Java Plugin2 (from Java SE 6 Update 10). I actually started to work on this one but for some weird reason, it seems there are still dependencies on XPCOM. Well, it wants the browser nsIServiceManager. Since I don't want to write a test plugin, I will need source code, or more happy days.

As announced in a previous blog entry, nspluginwrapper 1.0.0 was around the corner. I got some time this weekend to iron out the latest (cosmetic) problems. This version doesn't feature everything I wanted to include for a “1.0” release but it turns out to be rather stable for some time now. Missing features became either obsolete (XPCOM) or totally irrelevant (Windows support).

Here is a short list of changes since 0.9.91.5, details to follow:

• Don't wrap root plugins to system locations, keep them private
• Fix support for Acrobat Reader 8 (focus problems)
• Fix support for mozplugger (in full-debug mode)
• Fix support for WebKit
• Fix crashes with Flash Player 9 Update 3 (9.0.115)
• Improve error handling during RPC initialization (possible memory leak on error)
• Improve error handling in NPP_WriteReady() and NPP_Write()

Wrapping root plugins. Previous versions of nspluginwrapper used to incorrectly wrap root plugins system-wide. The fix introduced in this version is very minimalistic and works as follows: any plugin located under ~root will be wrapped into his private plugins directory (~root/.mozilla/plugins). If a wrapped root plugin is found in any system location during upgrade, it will be moved to the ~root private location instead. A better fix is planned for nspluginwrapper 1.2.0.

Acrobat Reader 8. A very stupid bug was introduced in version 0.9.91.5 which prevented Acrobat Reader 8 (8.1.2) from working correctly: no keyboard event was propagated to the plugin. This is now fixed. For reference, this problem is reported as Novell bug #353503. Thanks to Stanislav Brabec for reporting the issue.

WebKit. This release fixes support for WebKit-based browsers. In particular, this should fix WebKit bug #18883 whereby plugins were crashing on exit. However, you will also need a recent enough snapshot of WebKit (>= rev 33570, see WebKit bug #18882).

Flash Player. This release fixes support for Flash Player 9 on Linux for SMP or CMP systems.

There are some (unresolved) threading issues with Flash Player 9 on *BSD systems, in particular FreeBSD 6.1 and NetBSD 3.1. i.e. pages with only one Flash instance will work though multiple instances will fail because of multithreading. This may be an issue with the Linux emulator on those systems. Probably some TLS stuff or some Linux syscalls unsufficiently supported. BSD hackers should probably look into waitid, tgkill, futex syscalls and also coverage of newer CLONE_* flags.

Flash Player 10 Beta for Linux is working but you may encounter keyboard input problems with some sites. In particular, the usual Bloxorz game^W testcase at Addicting Games is failing again with this Beta. This is not an nspluginwrapper problem but a generic issue with Flash Player 10 Beta that also occurs with 32-bit web browsers.

Build system. Some –with options were moved to –enable style. In particular, –enable-biarch replaces –with-biarch and –enable-generic replaces –generic-build. Besides, the binaries are no longer stripped by default. Should you wish to strip the installed files, you have to configure your build with the –enable-strip option.

NSPluginWrapper 2.0.0 preview. There is no public preview of this because source code is currently ugly and maintaining three branches at a time was going to be a nightmare. Now that nspluginwrapper 1.0.0 is released, trunk will be the default development branch towards 1.2.0. Then, it will be branched out within the next few months for nspluginwrapper2 integration.

The primary goal of this project is not to rewrite its core functionality but rather to re-organize the source code so that it is more flexible and suitable for inclusion into third-party applications (public API). nspluginwrapper2 will also address support for OpenGL-rendered browsers, WebKit/Clutter in particular. Here is a short video to demonstrate this: Magic Pen in a WebKit actor. You can also note that the reflection texture accounts for the plugin texture (Magic Pen).

Hi, here a few updates concerning nspluginwrapper.

Project commodities. Many people asked for usual project commodities like mailing-lists and a bug reporting system. I don't want to host that myself because that would require users to create yet another account elsewhere. SourceForge or Savannah-based systems don't suit me because (i) I don't like the interface and (ii) I want to keep the SVN tree hosted on my server at this time (which Savannah wouldn't allow, AFAIK). So, where can I host the project?

• The ideal solution would be Mozilla.org since it is OS and distribution neutral and provides a Bugzilla. I don't know yet if this interests them. Hey, are there Mozilla people reading?

• The practical solution would be to accept the kind offer from Red Hat / Fedora: Fedora Hosted Projects Trac. It could be available immediately. However, I don't know if other people (distributors, *BSD people) would get frustrated by that or not (politics is always troublesome).

Standalone Player. Lately, I was working on a standalone NPAPI plugins player. The initial goal for that was to allow Flash games to be played without a complete web browser as the front-end. The syntax is actually what is used in <embed> tags. e.g. npplayer src=~/flash/bloxorz.swf width=640 height=480. The term “player” can sound crappy, this is because “viewer” is already used by the “client”, aka the program that actually executes the plugin.

OpenGL Rendering. What can you do when you have a standalone player? Well, apart from investigating some bugs, it can be used to experiment with… OpenGL rendering. I am not using texture-from-pixmap because of some other problems independent from me, so I am using an ugly hack that only works with Flash Player 9 at this time. The other benefit is that cursor changes are monitored and handled gracefully. The OpenGL back-end is using Clutter.

Now, you probably wonder: “what the hell is that useful for?”. Simple answer: initially allow Flash content to be played and interacted with in a Clutter+WebKit-based browser.

Here is the obligatory screenshot for the Clutter-based standalone NPAPI plugins player.

Movies are also available to show off: Magic Pen (reflection), Bloxorz (scaled), WebKit/Clutter (“complex” application like the Google Video player in Flash).

Roadmap. Due to recent developments, some major changes area also necessary. Here is a rough roadmap of the events. Note that I don't mention the dates because I don't know them yet… At least, I am now clear on the versioning that I promise to improve!

• Version 1.0: based on current 0.9.9x branch + some other bug fixes only
• Version 1.2: based on current trunk + Red Hat changes + standalone plugin player based on Gtk.
• Version 2.0: OpenGL rendering support + full SDK to allow third party programs (Gtk or Clutter-based) to embed NPAPI plugins. This will require some changes not suitable for 1.x series.

I am facing a cruel dilemma: on one hand, I want to continue the development of software I contributed to for years or software I created ; on the other hand, I have to realise I just can't pursue in all directions.

Free software is great to the end-user but it generates several costs to a developer, when he is not backed up by companies or sponsors. Yes, everything is done during his free time. In my opinion, this model works best when you are a student (lots of holidays!) or working for a company that develops free or open source software. Otherwise, you are rapidly caught by other costs if you try to get a “normal” life: (i) human costs, e.g. you sleep less because you are absorbed by your project(s), (ii) social costs because you are not devoting much time to other activities like hiking, partying/clubbing, getting in touch with years old friends, dating girls, etc.

About the financial costs. I generally buy what I need for development/testing purposes, without looking at the expenses. e.g. I bought MacOS X Leopard earlier this year whereas I really have no need to use it personally but for development (the system is still sub-optimal, I will get back to it in a future post). I am not developing shareware, so the money comes from my pockets. I recently sorted my papers and wanted to gather some stats about my computer hardware or software related expenses. I wish I hadn't as more than 70% of them were directly used for OSS development. I won't tell you the exact amount here but it looks quite indecent, even for a 7 years timeframe. Fortunately, some chipmakers were helpful, otherwise this would have increased the costs (though, by a very small margin)!

It's true that enthusiasts generally do not count the expenses of their hobbies, neither the time devoted to them. However, the latter can exactly be a problem for reasons I mentioned earlier. As a side note, I have been very busy the past months with other (personal) “projects”. Yes, you can think this is a very selfish decision to not finish some things I started earlier, but I wanted/needed to do other activities, e.g. lately, that was another sort of optimisation problems + sometimes nothing at all simply to relax my brain and sleep more the weekend! For the record, I generally sleep only 5 to 6 hours per night, which seems to be the optimal duration for me nowadays (vs. 8 to 9 hours 11 years ago), so only 3 long to 4 short sleep cycles. Even worse, the most optimal time to start to sleep is between 00:25 and 00:55, and I mean it. Last night, I tried 23:27 because I felt very sleepy. What a bad idea, I got up around 4:12!

Overall, in order to achieve my new personal goals, I came to the conclusion that I still need to reduce my OSS developments for at least the next 4 to 6 months. IOW, reduce to one project, at most. I know I failed to reply to your mails efficiently. However, I will try again but bear in mind I probably won't look at solutions right away. It's better I don't make you promises I might not honour…

Is there another solution? Yes, win the lottery and get rid of a full-time job so that one can devote any time he wants onto a particular project. However, let's get back to the real world, this is just highly unlikely to happen. So, costs reduction choices have to be made. This is a very difficult problem because I equally like every project I contribute to and they can require the same amount of time to work on. Further thoughts lead to the conclusion that I will be suspending any development on Basilisk II or SheepShaver. Why? Well, it was brought to my attention that Red Hat / Fedora uses nspluginwrapper by default. So, there is now probably more than a million nspluginwrapper users, either they know they use it or not (assuming desktop users would browse the Internet with contents requiring a plug-in). Henceforth, more people should benefit from nspluginwrapper development than from Mac emulators. Besides, I also need it for one professionnal project.

In summary:

• Basilisk II / SheepShaver: suspended. Note this doesn't mean indefinitely stopped, I still have many ideas planned and even started to implement some of them! It means I may get bored by other activities and come back to do what I used to be good at instead.
• NSPluginWrapper: active development. I will also post recent happenings around this project. You may be surprised to see what it could be used for nowadays. There will also likely be a new location to host the project with lists and bug reporting tools. SVN is already available here.

BTW, I came across Ohloh and I compiled the projects I work on to here. Ohloh has interesting metrics but I have several problems with it:

• The cost of a project is probably over-valued, at least in terms of human efforts (men-year).
• The name is somewhat crappy. Really, what the hell does “Ohloh” mean? Then, my brain tried some word associations and came by very bad ones. I hope the authors didn't meant that…

Hi, the website will be under maintenance from time to time, so don't be surprised if it is temporarily unavailable. Actually, there are some performance problems I would like to investigate: pages are served slowly, aren't they? e.g. this blog is served in about 2 seconds to wget but noticeably more when served to graphical browsers like Firefox or Safari. There are only 1200 unique visitors per day on this site, overall. So, for something like one visitor per minute, it's highly unlikely that the server, based on a VIA C7 @ 2 GHz, couldn't cope with that tiny load.

Further experiments show that a static version of the nspluginwrapper page can be served under 0.30 second vs 1.5 second for the dynamic page. I have installed PHP e-Accelerator and all pages are even cached internally by Dokuwiki, so XHTML is normally served directly instead of parsing the wiki pages again. I don't know yet what more could I do since I don't really grok PHP.

BTW, Dedibox announced newer servers (64-bit Celeron based on the Core 2 architecture, 2 GB of memory, etc.) for the same price level, so I will probably upgrade unless the “old-time users” are rewarded with a cheaper subscription, as this is currently rumored.

Note: I have upgraded to Dokuwiki 2007-06-26b, please tell me if you notice any problem. At least, the plugins upgrade also brought in some fixes to ToC generation on the front page. Some day, if I ever get more time, I will probably switch to Drupal.

Some people have reported that NSPluginwrapper crashes with the new Flash 9 Update 3 (9.0.115) plug-in. It turns out this is triggered in multithreaded context and is more visible on SMP/CMP machines. If you have crashes similar to those reported in RedHat #360891 or Ubuntu #177856, please try the following patch, or use this source snapshot for the upcoming version 0.9.91.6.

As a side note, I revived my Antec Aria box with a new PSU. It was somewhat kludgely to replace due to the many cables in there but it now works and is even more silent than before!

To SheepShaver users et al., I don't forget you either. Lately, I was working on a new video back-end using OpenGL for rendering. However, I still think MacOS X is under-efficient for graphics. In particular, the MacOS X kernel is so slow, wrt. Linux on the same machine, that it prevents some further optimisations, e.g. intercepting illegal writes to write-protected memory to track emulated video memory changes (dirty pages). I am not convinced that Leopard brings the expected performance improvements either, Mach syscalls and signals delivery is painfully slow!