Sourcing a docroot from a zip file

[0x6e6562]

Hi,

I'd like to embed Mochi as plugin into my application (RabbitMQ).

To make the addition of client apps as easy as possible, I'd like to
be able to bundle a client web in zip file that can be just dropped
into a plugins directory.

This zip file would contain static content (that I'd like to serve
with mochiweb_request:serve_file/2) as well as request_handlers for
any server side functionality.

I envisage that each plugin bundle is packaged as an OTP app - each
mochi client app would define an OTP application dependency on
mochiweb.

When each bundle is loaded, it would call a function to

a) register its docroot with the mochiweb app;
b) register its request handlers with mochi to repsond on specific
context roots;

Ideally I'd want to avoid having to explode the zip file within the
plugins directory.

Does anybody do something like this already? If not, what would be the
most sensible approach to this?

Thanks,

Ben

[Steve Davis]

Ben,

Take a look at the ".ez" experimental support added in OTP R12-5 and
improved in R13

Notably "Loading of Code From Archive Files" in
http://erlang.org/doc/man/code.html

Best,
Steve

[Ben Hood]

Steve,

On Fri, Jul 17, 2009 at 1:13 PM, Steve
Davis<steven.cha...@gmail.com> wrote:
>
> Ben,
>
> Take a look at the ".ez" experimental support added in OTP R12-5 and
> improved in R13

Thanks for the heads up, but unfortunately the code loading support
pertains to .beam and .app files as opposed to arbitrary files. Also,
the serve_file logic in mochiweb is designed around filehandles for
each requested object, and I don't think this would to easy to
shoehorn the zip API into this.

Ben

[Bob Ippolito]

So don't use serve_file, write your own function that does what
serve_file does. It doesn't do anything that you can't do yourself.
The request module isn't special.

-bob

[Ben Hood]

Bob,

On Fri, Jul 17, 2009 at 4:06 PM, Bob Ippolito<b...@redivi.com> wrote:
>> Thanks for the heads up, but unfortunately the code loading support
>> pertains to .beam and .app files as opposed to arbitrary files. Also,
>> the serve_file logic in mochiweb is designed around filehandles for
>> each requested object, and I don't think this would to easy to
>> shoehorn the zip API into this.
>
> So don't use serve_file, write your own function that does what
> serve_file does. It doesn't do anything that you can't do yourself.
> The request module isn't special.

Sorry, I was expressing myself badly - I think the fundamental problem
with the zip API is that you can't use an opened ZipHandle to
reference the contents of an individual file - doing a zip_get on a
file results in the file being unzipped to a directory or memory. The
former boils down to just unzipping and serving the file normally, the
latter doesn't give you a handle on the content of the extracted file,
so having it in memory is not going to help because you can't
reference it. So it's not really down do the request module anyway.

Ben