Alan Burlison's Work Related Ramblings

Friday January 27, 2006

Making file:// links work in thunderbird

I use thunderbird 1.5 as my mail reader, and it is always bugged me that clicks on file:// links in emails are ignored - these are frequently used internally within Sun, for example code reviews are usually done with a tool called webrev which builds a tree of HTML pages containing the diffs, and the file:// links are usually mailed out to reviewers. A spot of light googling revealed this page on the topic for firefox, and although the page implied the same configuration settings were also used by thunderbird, it wasn't quite clear how to apply the technique to mails read from an IMAP server. Hmm.

To try to figure out what was going on I opened up the thunderbird JavaScript console (on the Tools menu) and clicked on a file:// link in an email. The following error message appeared:

So I surmised that what I needed to do was to tell thunderbird to trust links from my IMAP server, so I added the following to my user.js file:

// Allow file:// links
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "imap://mailserver.uk.sun.com:143");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

restarted thunderbird, and clicking on file:// links now worked. Note that there are a number of good security-related reasons as to why this isn't enabled by default, so use it at your own risk!

Posted by alanbur ( Jan 27 2006, 01:02:25 PM GMT ) Permalink Comments [3]

Wednesday January 25, 2006

OpenSolaris appliances

I see my colleague Chris Gerhard has blogged about the new OpenSolaris Appliances community. Chris's list of requirements is pretty much identical to mine - others have added comments to his blog suggesting a raft of additional stuff, but I'm primarily interested in something that can act as a mail and web server as well as doing SMB filesharing. My constraints are that it must be small, quiet and run Solaris (natch!), so if you have any suggestions for where we should start on the hardware front, please head over to the forum and help us get started. I've disabled comments to encourage you to post over there and not here ;-)

Posted by alanbur ( Jan 25 2006, 05:28:05 PM GMT ) Permalink

Sunday January 15, 2006

WonDLLand revisited

I previously documented my problems getting my Java/JNI wrapper for OziAPI to work. As I said in my previous post, some of my problems were down to the OziAPI DLL not getting a chance to clean up properly when the application exited. Over the Xmas break I continued hacking away and wrapping more of the interface, but when I got to the OziExplorer callback hooks I hit another showstopper. The hooks allow you to trap mouse clicks on the map displayed in OziExplorer, but every time I activated one of the callback hooks and then clicked on a map the application hung, and it stayed hung until I quit the Java application. My initial thought was that I was falling afoul of the awful mess of calling convention types on Win32 and that something was barfing on a malformed stack frame somewhere on the round trip from my Java app to OziExplorer and back. I was particularly suspicious because I was using the MinGW tools to build the DLL containing my JNI code rather than the Microsoft tools.

To try to track down the root cause I hacked together a console-only C program and DLL to mimic my Java/JNI setup, and whilst that worked fine with the non-callback OziAPI functions (as did the Java/JNI version), any callback functions hung in just the same way as the Java/JNI version. I noticed that the Visual C++ example included with the OziAPI DLL contained a Windows GetMessage loop, so I added one to my toy program and hey presto, it worked! This implied that OziAPI uses windows messages to implement the callback mechanism, and an email to Des Newman, the OziExplorer developer, confirmed that was in fact the case.

That didn't really help explain what was wrong with the Java/JNI setup - the Java code was a Swing application, so it had to contain a Windows dispatch loop anyway - right? What on earth was going on? I was more more less ready to admit defeat when I stumbled across an old JavaWorld article that contained the following:

Ahah! So it appeared that it is necessary to have a custom dispatch loop to handle the Windows messages dispatched by the OziAPI callback hooks. However, because this thread has in turn got to be able to dispatch the callbacks to Java methods, we have to play nicely with the JVM as well. We also have to make sure that the events from the OziAPI DLL get dispatched to our dispatch thread - some experimentation revealed that OziAPI sends them to the first thread that makes a callback-related OziAPI call. Putting this all together, here's what is necessary to get it to work:

• Create a native Windows thread.
• Call PeekMessage(&msg, NULL, WM_USER, WM_USER, PM_NOREMOVE) to force creation of a new Windows message queue.
• Make a dummmy oziMapSingleClickOFF() call so OziAPI routes the callbacks to the new thread.
• Attach the new thread to the JVM with a call to AttachCurrentThread()
• Enter a message dispatch loop to handle the callback events.

The various OziAPI calls necessary to enable and disable the callback hooks are also made from inside the new thread - the event loop responds to custom WM_APP messages and enables or disables the callbacks as required. The callbacks themselves are handled by C routines that vector the events to the appropriate Java method calls. I've left out all details of the necessary inter-thread synchronisation that's needed, but that's an overview of how it all hangs together.

I'm still working on wrapping the rest of the API - it's rather large so it is going to take a while, but once I have it knocked into shape I'm intending to release the code here on SourceForge.

Posted by alanbur ( Jan 15 2006, 11:26:11 PM GMT ) Permalink Comments [0]

Monday January 09, 2006

An opensolaris.org hack: customisable RSS feeds

In a (rather futile!) attempt to keep my email volume down slightly I've taken to reading some of the OpenSolaris mailing lists / forums via the RSS feeds provided by the site. I use the most excellent Sage plugin for Firefox. You can find a list of all the available opensolaris.org RSS feeds here - there are four (!) variants for each OpenSolaris forum, plus roll-up feeds for each group of forums. Be aware that there's a glitch on the webpage and the feed type icons are mislabelled - the "Threads" (one big speech bubble) and "Messages" (two small speech bubbles) labels are transposed, although I'm sure Derek will have that sorted out shortly - if you hover over the icons in the feed list, the "Threads" URLs all contain rssthreads.jspa and the "Messages" links contain rssmessages.jspa.

One of my favorite feeds is the popular threads feed, which shows you the threads with the most activity. I also subscribe to a few individual forum feeds, such as the OpenSolaris discuss one, but something that has always niggled me is that you only see the last 10 threads, which really isn't enough. However it is possible to change this by modifying the bookmark you use for the feed - simply stick &numItems=20 on the end of the bookmark URL. The full list of options are called out in the Jive documentation. Unfortunately, despite what the documentation suggests this doesn't work for "popular threads" feeds, which is a shame.

Posted by alanbur ( Jan 09 2006, 11:07:19 AM GMT ) Permalink Comments [0]