xulrunner: accessing files in jar archives

[Christoph Dorn]

I am going through the motions of bundling a narwhal-based firefox
extension and have run into a roadblock: Extension files packed into jar
files.

At this time the narwhal-xulrunner engine only supports filesystem based
file paths. Not urls pointing to files in jar archives such as:

jar:file:///data/.../extensions/te...@test.com/packages.jar!/test/echo.js

I am eager to get this working but am stuck on how to test for, iterate
and read files from jar archives.

Any suggestions on how I should go about this?

Thanks!

Christoph

[Zachary Carter]

If the jar files are mapped to a chrome URL, then you can use nsIChannel to read them[1]. What's your use case here? Do we need to add this to IO/require?

[1]: http://forums.mozillazine.org/viewtopic.php?p=921150#921150

--
Zach Carter
http://zach.carter.name

[Christoph Dorn]

Zachary Carter wrote:
> If the jar files are mapped to a chrome URL, then you can use nsIChannel
> to read them[1]. What's your use case here? Do we need to add this to
> IO/require?

The files *are* mapped to a chrome URL using "resource://". Using
nsIChannel will work only for *reading* them.

The extension works with all files flat on the filesystem (as during
development). For distribution, extension files should be in jar
archives. narwhal-xulrunner should handle this underlying change
transparently. This is not the case right now as it uses full filesystem
paths to read modules.

If we access all narwhal modules via "resource://narwhal/..." and all
program modules via another resource URL we can make this automatic I think.

A resource URL if mapped to a jar file will convert to:

jar:file:///data/.../extensions/te...@test.com/packages.jar!/test/echo.js

This provides all info we need to use nsIZipReader to check if a file
exists, iterate directories and read.

I am wondering if nsIZipReader is the best solution for this. I was
hoping to tie into the same interface used internally when xulrunner
services chrome URL's from jar files to make this most efficient.

I do think we may need to add this to the IO layer (to provide
abstraction) but in a *read only* mode since the jar files are static.

Christoph

>
> [1]: http://forums.mozillazine.org/viewtopic.php?p=921150#921150
>
> On Fri, Nov 6, 2009 at 12:27 AM, Christoph Dorn

> <christ...@christophdorn.com <mailto:christ...@christophdorn.com>>

> wrote:
>
> I am going through the motions of bundling a narwhal-based firefox
> extension and have run into a roadblock: Extension files packed into jar
> files.
>
> At this time the narwhal-xulrunner engine only supports filesystem based
> file paths. Not urls pointing to files in jar archives such as:
>
> jar:file:///data/.../extensions/te...@test.com/packages.jar!/test/echo.js

> <http://te...@test.com/packages.jar%21/test/echo.js>

[Irakli Gozalishvili]

Hi !!

Sorry for the late replay!  I do have implementation somewhere of all kind of stuff operations on zipped archives like read write zip unzip and it's on my todo list to port it to narwhal.

I'm also playing with jetpacks version of module loader in order to  use instead, not sure yet if it will be right choice, but at least I'm looking at the idea they have with the CompositeFileSystem and I do think it's probably the right way to go.

I'll be back from conference on monday and will try to write more details on some of my thoughts I have in that direction.

Regards   
--
Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Phone: +31 614 205275
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

>     <http://test@test.com/packages.jar%21/test/echo.js>

[Tom Robinson]

As with zip file support (jars are just special zips, right?) we'll
need custom loaders.

As you're aware, currently the Narwhal loaders are all based on the
filesystem. A module must be in the filesystem in one of the search
paths. We need to add hooks to allow a loader to provide "virtual"
search paths (for lack of a better term), which map module ids to
module factories. This will allow things like modules compiled into
the binary, zips, jars, etc.

This could also be useful for browser deployment, if we want to unify
the browser loader with the sandbox module (I think they're separate
right now).

I know Kris was doing some refactoring of the sandbox module so maybe
he can comment.

-tom

[Christoph Dorn]

Tom Robinson wrote:
> As with zip file support (jars are just special zips, right?) we'll
> need custom loaders.

Yes, Jars are zips.

> As you're aware, currently the Narwhal loaders are all based on the
> filesystem. A module must be in the filesystem in one of the search
> paths. We need to add hooks to allow a loader to provide "virtual"
> search paths (for lack of a better term), which map module ids to
> module factories. This will allow things like modules compiled into
> the binary, zips, jars, etc.

Ah yes. That makes sense.

Any volunteers to add hooks for "virtual" search paths and a sample zip
loader [1]? I have too much on my plate :(

Christoph

[1] - http://github.com/tlrobinson/narwhal/issues/#issue/67

[Christoph Dorn]

Irakli Gozalishvili wrote:
> Sorry for the late replay! I do have implementation somewhere of all
> kind of stuff operations on zipped archives like read write zip unzip
> and it's on my todo list to port it to narwhal.

Anything you can share now? Sample code on working with zip files would
help me a lot.

> I'm also playing with jetpacks version of module loader in order to use
> instead, not sure yet if it will be right choice, but at least I'm
> looking at the idea they have with the CompositeFileSystem and I do
> think it's probably the right way to go.

CompositeFileSystem? Do you have more info on that?

Christoph