From: Erik P. <er...@ad...> - 2003-04-24 18:26:56
|
Hi, I've just started tinkering with Yaws and have a couple of questions. First, I'd like to be able to map a url or url pattern to a specific function. Is that possible (currently) in Yaws? If not, any plans? Secondly, I'm wondering what differentiates Yaws from the inets httpd. It looks like Yaws is targeted as a standalone webserver and inets httpd is more targeted as an embedded server. Thanks! Erik Pearson |
From: Torbjorn T. <to...@bl...> - 2003-04-24 19:31:40
|
Erik Pearson wrote: > Hi, > > I've just started tinkering with Yaws and have a couple of questions. > > First, I'd like to be able to map a url or url pattern to a specific > function. Is that possible (currently) in Yaws? If not, any plans? Not sure about 'patterns' but look at the appmods directive. It makes it possible to hook into the processing of the URLs. > > Secondly, I'm wondering what differentiates Yaws from the inets httpd. > It looks like Yaws is targeted as a standalone webserver and inets httpd > is more targeted as an embedded server. It is intended to be used in both cases. Nortel is using it in 'embedded mode' in their SSL-VPN product. BTW: I'm in the process of converting the Bluetail Ticket Tracker to run embedded Yaws instead of the inets server. Cheers , Tobbe |
From: Erik P. <er...@ad...> - 2003-04-24 21:55:33
|
On Thursday, April 24, 2003, at 12:31 PM, Torbjorn Tornkvist wrote: > > > Erik Pearson wrote: >> Hi, >> I've just started tinkering with Yaws and have a couple of questions. >> First, I'd like to be able to map a url or url pattern to a specific >> function. Is that possible (currently) in Yaws? If not, any plans? > > Not sure about 'patterns' but look at the appmods directive. > It makes it possible to hook into the processing of the URLs. That gets part of the way there. I'd like to be able to have the function invoked by a more flexible matching mechanism, though. E.g. a path (with remainder passed to the function), a url suffix, or regular expression. Maybe I'll do some actual work and see what would be required to implement it. > >> Secondly, I'm wondering what differentiates Yaws from the inets >> httpd. It looks like Yaws is targeted as a standalone webserver and >> inets httpd is more targeted as an embedded server. > > It is intended to be used in both cases. Nortel is using it in > 'embedded mode' in their SSL-VPN product. > > BTW: I'm in the process of converting the Bluetail Ticket Tracker > to run embedded Yaws instead of the inets server. Might I ask what it is about Yaws that makes it more attractive to you? Thanks, Erik. > > Cheers , Tobbe > > Erik Pearson Adaptations desk +1 510 527 5437 cell +1 510 517 3122 |
From: Torbjorn T. <to...@bl...> - 2003-04-25 08:50:31
|
Erik Pearson wrote: >> >> BTW: I'm in the process of converting the Bluetail Ticket Tracker >> to run embedded Yaws instead of the inets server. > > > Might I ask what it is about Yaws that makes it more attractive to you? It is on sourceforge, i.e I can repair/add things, and of course Klacke is sitting in the same office.... ;-) Cheers , Tobbe |
From: Claes W. <kl...@hy...> - 2003-04-26 19:16:10
|
On Thu, Apr 24, 2003 at 11:25:54AM -0700, Erik Pearson wrote: > Hi, > > I've just started tinkering with Yaws Nice > and have a couple of questions. I'll try to answer ... > > First, I'd like to be able to map a url or url pattern to a specific > function. Is that possible (currently) in Yaws? If not, any plans? As tobbe already pointed out, we habe the appmod thing. I's not mapping patterns, merely postfixes of URLs. It's certainly implementable to have patterns instead of postfixes, however one of the main concerns with yaws has been and stil lare ... performance. And running regex:something .. on each and every GET req, sucks. , I'm wondering what differentiates Yaws from the inets httpd. Yaws is faster, but above all i.s faster and more flexible when we want to generate dyn content. Which we do ... don't we ? It's designed to generate dyn content, fast. > looks like Yaws is targeted as a standalone webserver and inets > httpd is more targeted as an embedded server. > Not, its equally likely that we use Yaws for standalone server as well as embedded server. I use it for both, it fits perfectly into an existing erlang app, and it's easy to run as .. i.e apache replacement. Cheers and good luck ... /klacke Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control |
From: Claes W. <kl...@hy...> - 2003-04-26 22:09:36
|
> As tobbe already pointed out, we habe the appmod thing. I's > not mapping patterns, merely postfixes of URLs. prefixes .. that is. /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control |
From: Erik P. <er...@ad...> - 2003-04-27 00:46:42
|
hi Claes, Thanks for the info, it all makes sense. On the issue of mapping path handlers to functions, I'd agree that regex stuff would slow down access to a site. However, the simple matching patterns shouldn't slow things down too much, and one could always take the attitude of letting users digging their own ditches. I've used other web servers based on functional languages (AllegroServe with Franz CL, e.g.) that allow this mapping, and it is durn fun to play with. Standard access modes as well (e.g. file, cgi) can be provided or removed by adding a new handler. It looks like yaws has some built-in dependencies to files (e.g. /var) in various places. It would be great if all of this could be routed through functions supplied by the user. The idea being that everything could be controlled by code. Finally, and I don't want to wear out the welcome mat but what the heck, it would be great if every pivot point could be passed through a kind of "handler" filter. E.g., the handling of GET and POST requests are hard coded into the server, it looks like. However, why not have the appropriate method handler pulled from a list of registered handlers? This would make it easy for special-purposing a site, and for handling whatever set of HTTP request types a site requires (either reducing the set or expanding it.) Anyway, I don't think that any of this would be terribly hard to implement, this being functional programming land, but would be an architectural shift. Of course, I'm *always* looking for the perfect programmable web server to hitch my wagon to! Erik. On Saturday, April 26, 2003, at 12:15 PM, Claes Wikstrom wrote: > On Thu, Apr 24, 2003 at 11:25:54AM -0700, Erik Pearson wrote: >> Hi, >> >> I've just started tinkering with Yaws > > Nice > >> and have a couple of questions. > > > I'll try to answer ... > >> >> First, I'd like to be able to map a url or url pattern to a specific >> function. Is that possible (currently) in Yaws? If not, any plans? > > > As tobbe already pointed out, we habe the appmod thing. I's > not mapping patterns, merely postfixes of URLs. > > It's certainly implementable to have patterns instead of > postfixes, however one of the main concerns with yaws has been > and stil lare ... performance. And running regex:something .. on each > and every GET req, sucks. > > > , I'm wondering what differentiates Yaws from the inets httpd. > > > Yaws is faster, but above all i.s faster and more flexible when > we want to generate dyn content. Which we do ... don't we ? > It's designed to generate dyn content, fast. > > > >> looks like Yaws is targeted as a standalone webserver and inets >> httpd is more targeted as an embedded server. >> > > > Not, > its equally likely that we use Yaws for standalone server as well > as embedded server. I use it for both, it fits perfectly into an > existing > erlang app, and it's easy to run as .. i.e apache replacement. > > Cheers > > > and good luck ... > > > /klacke > > > Claes Wikstrom -- Caps lock is nowhere and > http://www.hyber.org -- everything is under control > Erik Pearson Adaptations desk +1 510 527 5437 cell +1 510 517 3122 |
From: Claes W. <kl...@hy...> - 2003-04-28 12:51:45
|
On Sat, Apr 26, 2003 at 05:45:40PM -0700, Erik Pearson wrote: > hi Claes, > > Thanks for the info, it all makes sense. On the issue of mapping path > handlers to functions, I'd agree that regex stuff would slow down > access to a site. However, the simple matching patterns shouldn't slow > things down too much, Hmmm a bit easier said than done...... take a look at the code in yaws_server:split_path which is the code that decides wether we have an appmod or not. > and one could always take the attitude of letting > users digging their own ditches. I've used other web servers based on > functional languages (AllegroServe with Franz CL, e.g.) that allow this > mapping, and it is durn fun to play with. Standard access modes as well > (e.g. file, cgi) can be provided or removed by adding a new handler. > Ok ... more handlers, callbacks etc etc :-) > It looks like yaws has some built-in dependencies to files (e.g. /var) > in various places. It would be great if all of this could be routed > through functions supplied by the user. The idea being that everything > could be controlled by code. Here I agree _completely_. This should definitely be removed. The only deps im certain of are the ones in the install script though. Yaws itself runs fine without /var > > Finally, and I don't want to wear out the welcome mat but what the > heck, it would be great if every pivot point could be passed through a > kind of "handler" filter. E.g., the handling of GET and POST requests > are hard coded into the server, it looks like. However, why not have > the appropriate method handler pulled from a list of registered > handlers? This would make it easy for special-purposing a site, and for > handling whatever set of HTTP request types a site requires (either > reducing the set or expanding it.) > > Anyway, I don't think that any of this would be terribly hard to > implement, this being functional programming land, but would be an > architectural shift. Of course, I'm *always* looking for the perfect > programmable web server to hitch my wagon to! > Mapping GET(...) to mymod:myGet(...) , well that is easy. How to use it though, well a bit harder. We now have (atleast) the following possibilities to customize the actual behaviour of Yaws. - appmods. - arg rewrite - errormod_404 - errormod_crash - tilde_expand I am more than open for suggestions on further ways to make Yaws more custimizable. As always though, most software one writes is written because one needs it onself. I use all of the above features myself except for the arg rewrite which I added soley because I thought it was useful. Anyway, your "handler filters" ... have a look at the arg rewrite. It is a "pivot point handler filter" except you don't get actual HTTP control. You don't want that though, one of the things you really want the webserver to do for u, Is all gory HTTP 1.1 chunkes and such. Anyway, have a look at the arg rewriter. The default is yaws:arg_rewrite(Arg) which does nothing. Set another mod in the conf and u are in the air. You can even do your regex URL filtering there, especially if you combine it with appmods. /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control |