|
|
I've been using ImageJ to view volume data served through a Web
application. I serve up an ImageJ macro file, and define ImageJ as the
helper application. Thanks to Wayne's latest improvements, ImageJ
automatically runs and hides the macro, which instructs ImageJ to run
our plug-in (a version of Virtual Stack Opener that loads slices
through a Web service rather than from disk).
I'm having trouble, though, getting this scheme to work with browsers
other than Mozilla/Netscape.
I serve the macro file as "nnnnn.txt", since ImageJ expects .txt files
to contain macros, and I specify its content-type as
"text/imagej-macro-autorun". When Mozilla first sees a response with
this content-type, it asks what to do with the file; I specify "open
using ImageJ", and everything's fine.
Unfortunately, it appears that FireFox and Internet Explorer look only
at the file extension when deciding how to handle a file. Since I
don't want my users to make their browsers open *every* .txt file in
ImageJ, this makes things difficult. (It looks like Win XP SP2
provides a way to make IE sniff mime-types instead of relying on
filename extensions, but it looks like this is fraught with other
difficulties, and I don't want to impose them on my users. I live in
OS X, so I'm blissfully ignorant of the finer points of Windows
security policy.)
It seems to me that the easiest way to solve this problem would be to
let ImageJ recognize another filename extension identifying macro
files. We could still accept ".txt", so no old systems would break,
but we could also recognize (say) ".ijm". This way, I could train
recalcitrant browsers to just recognize the .ijm extension, and ImageJ
would still work with both old and new macro files.
Wayne, does this seem like a reasonable idea? Has anybody else on the
list found another way to solve this problem (launching macros in
ImageJ as a browser helper app)?
Thanks!
--
-jeffB (Jeff Brandenburg, Duke Center for In-Vivo Microscopy)
|
Locked
