Erlang Mailing Lists

Author Message

<  Yaws mailing list  ~  Patch to reload mime types each type yaws starts

Guest
Posted: Sat Oct 31, 2009 11:50 am Reply with quote
Guest
Hi,

I had a requirement wherein changes to /etc/mime.types come into effect without requiring rebuilding yaws.

So I patched yaws to use the ets table created while parsing mime.types for returning mime types and to rebuild the ets
each time yaws starts.


The patch is on Yaws-1.77 tree.

Let me know if there are better ways of doing this.

Also the idea of compiling in mime type mappings is for throughput ?
Guest
Posted: Sat Oct 31, 2009 1:59 pm Reply with quote
Guest
On Sat, Oct 31, 2009 at 7:49 AM, Koushik Narayanan <koushik.list@gmail.com (koushik.list@gmail.com)> wrote:
Quote:
Hi,

I had a requirement wherein changes to /etc/mime.types come into effect without requiring rebuilding yaws.


Technically, you need to rebuild only the mime types module.


Quote:
So I patched yaws to use the ets table created while parsing mime.types for returning mime types and to rebuild the ets
each time yaws starts.


The patch is on Yaws-1.77 tree.

Let me know if there are better ways of doing this.

Also the idea of compiling in mime type mappings is for throughput ?
Guest
Posted: Sat Oct 31, 2009 3:12 pm Reply with quote
Guest
Hi,

On Sat, Oct 31, 2009 at 7:28 PM, Steve Vinoski <vinoski@ieee.org (vinoski@ieee.org)> wrote:
Quote:

Quote:
I had a requirement wherein changes to /etc/mime.types come into effect without requiring rebuilding yaws.



Technically, you need to rebuild only the mime types module.


Yes. The scenario is I have a binary package of yaws given to a system administrator wants to add/remove MIME types.


Quote:



I guess that depends on how you use it. One, if you update the mime types and rebuild the mime types module, all you need to do is redeploy its beam file, not all of yaws. Second, if you start yaws in a manner that allows you to remsh or rpc into it, you can leave it running and just hot-reload the new mime types module on the fly without restarting yaws at all. This reload logic could easily be written in a small shell script, for example.



Ok. But that would mean having an erl file generated at the deployment machine and compiled there. Though the erlang installations have both the compiler and the runtime installed, generally it wouldn't be required to have a compiler at a deployment machine.
Guest
Posted: Sat Oct 31, 2009 4:32 pm Reply with quote
Guest
On Sat, Oct 31, 2009 at 11:12 AM, Koushik Narayanan <koushik.list@gmail.com (koushik.list@gmail.com)> wrote:
Quote:
Hi,

On Sat, Oct 31, 2009 at 7:28 PM, Steve Vinoski <vinoski@ieee.org (vinoski@ieee.org)> wrote:
Quote:

Quote:
I had a requirement wherein changes to /etc/mime.types come into effect without requiring rebuilding yaws.



Technically, you need to rebuild only the mime types module.



Yes. The scenario is I have a binary package of yaws given to a system administrator wants to add/remove MIME types.


Quote:



I guess that depends on how you use it. One, if you update the mime types and rebuild the mime types module, all you need to do is redeploy its beam file, not all of yaws. Second, if you start yaws in a manner that allows you to remsh or rpc into it, you can leave it running and just hot-reload the new mime types module on the fly without restarting yaws at all. This reload logic could easily be written in a small shell script, for example.




Ok. But that would mean having an erl file generated at the deployment machine and compiled there. Though the erlang installations have both the compiler and the runtime installed, generally it wouldn't be required to have a compiler at a deployment machine.




Why does it have to be generated at the deployment host? A beam file is a beam file; it can be generated anywhere and run anywhere.


You don't really need a separate compiler, BTW, given that the compile module is always available by default in Erlang/OTP unless you take it out. If you're changing mime.types, you can generate a new one from an erlang shell by calling mime_type_c:compile(), assuming the yaws ebin directory is in the erlang code path and your working directory is where mime.types resides. This will generate a new mime_types.erl source module. You can then compile that either using the c(mime_types) erl shell command, which will also load it for you, or by calling compile:file("mime_types") and then using the code module to load the object code. Either way, doing this from a shell script is quite easy. Also, this can all be done via a remsh to a running yaws instance, in which case generating and compiling the new mime_types module will load it right into your running web server.


Guest
Posted: Sun Nov 01, 2009 3:14 am Reply with quote
Guest
Hi,

On Sat, Oct 31, 2009 at 10:00 PM, Steve Vinoski <vinoski@ieee.org (vinoski@ieee.org)> wrote:
Quote:


On Sat, Oct 31, 2009 at 11:12 AM, Koushik Narayanan <koushik.list@gmail.com (koushik.list@gmail.com)> wrote:
Quote:
Ok. But that would mean having an erl file generated at the deployment machine and compiled there. Though the erlang installations have both the compiler and the runtime installed, generally it wouldn't be required to have a compiler at a deployment machine.






Why does it have to be generated at the deployment host? A beam file is a beam file; it can be generated anywhere and run anywhere.


You don't really need a separate compiler, BTW, given that the compile module is always available by default in Erlang/OTP unless you take it out. If you're changing mime.types, you can generate a new one from an erlang shell by calling mime_type_c:compile(), assuming the yaws ebin directory is in the erlang code path and your working directory is where mime.types resides. This will generate a new mime_types.erl source module. You can then compile that either using the c(mime_types) erl shell command, which will also load it for you, or by calling compile:file("mime_types") and then using the code module to load the object code. Either way, doing this from a shell script is quite easy. Also, this can all be done via a remsh to a running yaws instance, in which case generating and compiling the new mime_types module will load it right into your running web server.


Agreed. But adding lines to a text file would certainly be easier.

Display posts from previous:  

All times are GMT
Page 1 of 1
This forum is locked: you cannot post, reply to, or edit topics.

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum