I think that to generalize the interface between ErlyWeb and the web server(s) it runs on, the connector should define the following function:
out(A, AppName, RequestStr) -> Response. A is an opaque record that encapsulates the request. ErlyWeb will just pass it down to the controller functions without inspecting or changing it. I'm not sure what information MochiWeb passes to the application handler and to what degree it overlaps with the Yaws arg, but ideally this request record should contain the same fields regardless of which web server you're using. AppName is the application's name, as a string (this corresponds to the opaque field currently defined in the Yaws server settings). ErlyWeb will use it to derive the app metadata module name, i.e. [AppName]_erlyweb_data. (Alternatively, this can be the derived atom instead of the appname string. This would "leak" some ErlyWeb internals to the connector, but would be slightly more efficient than passing a string because ErlyWeb wouldn't have to call list_to_atom().) RequestStr is the equivalent of the appmoddata field that's currently part of the Yaws arg. For example, if the appmod base is "/" and the browser requests "http://myapp.com/foo/bar/baz";, this would be "/foo/bar/baz". As a special case, if the browser requests "http://myapp.com";, this would be "/". ErlyWeb uses this value to derive the controller/function/parameters for the request. Response is currently any appmod response value that Yaws accepts. I'm not sure if all of these values can be generalized to MochiWeb and other servers. However, if the connector could translate these values for all servers, this would allow seamlessly porting existing applications between servers without any work. Yariv On Nov 12, 2007 1:09 PM, Filippo Pacini <[EMAIL PROTECTED]> wrote: > > I've only used yaws for now and gave a quick look to mochiweb and > iserve, but I'd like to test one of the two sooner or later. > > For the interface following python's wsgi implementation we can think at > it as having two sides: the "server" or "gateway" side and the > "framework" one. > The framework side is a module providing a fun (e.g. handle_req) > accepting an environment record (basically a wrapper around the http > request and containing also data specific for the framework) and a > callback from the "gateway" side to send the response to the server. > The server/gateway for every http request it translates the request data > from the server format to the environment format and invokes the > application fun. > > I should already have some code written. I'll try to improve it, test at > least with mochiweb and yaws and put it online somewhere. > Suggestions for a name? erlwsgi seems quite ugly. > > filippo > > > Roberto Saccon wrote: > > I actually started long time ago to make erlyweb work with iserve, but > > never got to a point where it actually worked. > > Anyway, erlyweb on mochiweb would rock, and a common gateway interface > > even more ! > > > > Filippo, do you have a concrete suggestion for such a gateway > > interface ? > > > > For using mochiweb to replace yaws you need to be aware that mochiweb > > is not a webserver (you have to build one from scratch using > > mochiweb) and does not offer anything for static file serving, so you > > need either to rely purely on a CDN, or another webserver (Lighttpd or > > nginx) or add static fileserving and ETAG handling to mochiweb. > > > > regards > > Roberto > > > >> Hi, > >> at the moment we have at least four different erlang web servers (yaws, > >> mochiweb, inets_httpd and iserve). IMHO it would be a good idea having a > >> little gateway interface like python's > >> wsgi:http://www.python.org/dev/peps/pep-0333/ > >> > >> This would allow easily building frameworks and libraries abstracting > >> from the underlying server. You write frameworks and libraries using the > >> gateway interface without worrying whether you are working with yaws, > >> mochiweb or whatever. > >> > >> I've been thinking about this for a while but hadn't have much time to > >> work on it yet. > >> What do you think? > >> > >> cheers, > >> filippo > >> > >> Yariv Sadan wrote: > >>> Now there's definitely a good reason to remove the dependency on the > >>> Yaws arg. It shouldn't be too hard -- I think the only internal > >>> dependency is where ErlyWeb inspects the appmod to derive the > >>> requested component. If anyone wishes to use ErlyWeb with MochiWeb, it > >>> would be great it they took on this little project and contributed > >>> their work. (I've already started using Yaws for Vimagi, so I don't > >>> want to go through the trouble of switching, but MochiWeb does look > >>> like a great alternative for new apps.) > >>> On Nov 11, 2007 10:15 PM, Robin <[EMAIL PROTECTED]> wrote: > >>>> MochiWeb was recently open sourced: > >>>> Announcement: > >>>> http://bob.pythonmac.org/archives/2007/11/07/mochiweb-another-faster-... > >>>> Google Code: > >>>> http://code.google.com/p/mochiweb/ > >>>> Google Group: > >>>> http://groups.google.com/group/mochiweb > >>>> ErlyMochiWeb anyone? > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "erlyweb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en -~----------~----~----~----~------~----~------~--~---
