| Author |
Message |
|
| Guest |
 Posted: Mon Nov 12, 2007 6:56 am |
 |
|
|
Guest
|
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 <robi123@gmail.com> wrote:
>
> MochiWeb was recently open sourced:
>
> Announcement:
> http://bob.pythonmac.org/archives/2007/11/07/mochiweb-another-faster-web-server/
>
> Google Code:
> http://code.google.com/p/mochiweb/
>
> Google Group:
> http://groups.google.com/group/mochiweb
>
> ErlyMochiWeb anyone?
>
>
> On Sep 27, 2:00 am, Robin <robi...@gmail.com> wrote:
> > Hey Bob, mochiweb could be a nice lightweight container for erlyweb
> > apps, any hint when you will 'properly' open source it?
> >
> > On Sep 26, 11:30 pm, "Bob Ippolito" <b...@redivi.com> wrote:
> >
> > > Before we switched from yaws to mochiweb, we had a module "mochiyaws"
> > > that had accessor functions for the yaws arg such that we could return
> > > something consistent regardless of the yaws version and without
> > > polluting the rest of our code with yaws include files.
> >
> > > -bob
> >
> > > On 9/26/07, Yariv Sadan <yarivsa...@gmail.com> wrote:
> >
> > > > Ugh, it's really annoying how every Yaws version treats the appmod
> > > > differently. However, I'm a bit wary of breaking existing apps by
> > > > passing something different from the arg. Also, supporting other web
> > > > servers using an adapter sounds like a good concept, but I'm not sure
> > > > than in practice anyone needs it. Please correct me if I'm wrong.
> >
> > > > Yariv
> >
> > > > On 9/25/07, Robin <robi...@gmail.com> wrote:
> >
> > > > > Hey Yariv! This is the same Robin from Erlounge...
> >
> > > > > Ironically, tonight I am using the new Yaws 1.71 and ErlyWeb 0.6.2 is
> > > > > now adding an extra '/' in the paths.
> >
> > > > >http://localhost:3000/blog//post/list/1
> > > > >http://localhost:3000/blog//post/new
> > > > >http://localhost:3000/blog//post/edit/1
> > > > >http://localhost:3000/blog//post/edit/2
> >
> > > > > (note the extra '/' on all the paths)
> >
> > > > > start_yaws()->
> > > > > code:add_patha("/opt/local/lib/yaws/ebin"),
> > > > > code:add_patha("./apps/blog/ebin"),
> > > > > erlyweb:compile("./apps/blog",[{auto_compile, true},{erlydb_driver,
> > > > > mnesia }]),
> > > > > yaws:start_embedded("./apps/blog/www",[{servername, "localhost"},
> > > > > {port, 3000},
> > > > > {appmods,[{"blog",erlyweb}]},
> > > > > {opaque,[{"appname",blog}]},
> > > > > {allowed_scripts,[]}],
> > > > > [{logdir,"./log"}]).
> >
> > > > > The problem could be caused by unfiltered use of the Yaws args, but I
> > > > > have not debugged it yet.
> >
> > > > > Back to the topic...
> >
> > > > > You are right that Erlyweb does not need all the fields of Yaws arg.
> > > > > The Yaws arg seems to have lots of unused fields that get carried
> > > > > around inside Erlyweb.
> >
> > > > > Using an ErlyWeb record that is adapted from a filtered version of the
> > > > > Yaws arg would help isolate future modifications to the adapter code
> > > > > when Yaws arg changes.
> >
> > > > > Also, adapters could be made to support other web servers.
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Nov 12, 2007 9:22 am |
|
|
|
Guest
|
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 <robi123@gmail.com> wrote:
>> MochiWeb was recently open sourced:
>>
>> Announcement:
>> http://bob.pythonmac.org/archives/2007/11/07/mochiweb-another-faster-web-server/
>>
>> 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 erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Nov 12, 2007 10:01 am |
|
|
|
Guest
|
MochiWeb was recently open sourced:
Announcement:
http://bob.pythonmac.org/archives/2007/11/07/mochiweb-another-faster-web-server/
Google Code:
http://code.google.com/p/mochiweb/
Google Group:
http://groups.google.com/group/mochiweb
ErlyMochiWeb anyone?
On Sep 27, 2:00 am, Robin <robi...@gmail.com> wrote:
> Hey Bob, mochiweb could be a nice lightweight container for erlyweb
> apps, any hint when you will 'properly' open source it?
>
> On Sep 26, 11:30 pm, "Bob Ippolito" <b...@redivi.com> wrote:
>
> > Before we switched from yaws to mochiweb, we had a module "mochiyaws"
> > that had accessor functions for the yaws arg such that we could return
> > something consistent regardless of the yaws version and without
> > polluting the rest of our code with yaws include files.
>
> > -bob
>
> > On 9/26/07, Yariv Sadan <yarivsa...@gmail.com> wrote:
>
> > > Ugh, it's really annoying how every Yaws version treats the appmod
> > > differently. However, I'm a bit wary of breaking existing apps by
> > > passing something different from the arg. Also, supporting other web
> > > servers using an adapter sounds like a good concept, but I'm not sure
> > > than in practice anyone needs it. Please correct me if I'm wrong.
>
> > > Yariv
>
> > > On 9/25/07, Robin <robi...@gmail.com> wrote:
>
> > > > Hey Yariv! This is the same Robin from Erlounge...
>
> > > > Ironically, tonight I am using the new Yaws 1.71 and ErlyWeb 0.6.2 is
> > > > now adding an extra '/' in the paths.
>
> > > >http://localhost:3000/blog//post/list/1
> > > >http://localhost:3000/blog//post/new
> > > >http://localhost:3000/blog//post/edit/1
> > > >http://localhost:3000/blog//post/edit/2
>
> > > > (note the extra '/' on all the paths)
>
> > > > start_yaws()->
> > > > code:add_patha("/opt/local/lib/yaws/ebin"),
> > > > code:add_patha("./apps/blog/ebin"),
> > > > erlyweb:compile("./apps/blog",[{auto_compile, true},{erlydb_driver,
> > > > mnesia }]),
> > > > yaws:start_embedded("./apps/blog/www",[{servername, "localhost"},
> > > > {port, 3000},
> > > > {appmods,[{"blog",erlyweb}]},
> > > > {opaque,[{"appname",blog}]},
> > > > {allowed_scripts,[]}],
> > > > [{logdir,"./log"}]).
>
> > > > The problem could be caused by unfiltered use of the Yaws args, but I
> > > > have not debugged it yet.
>
> > > > Back to the topic...
>
> > > > You are right that Erlyweb does not need all the fields of Yaws arg.
> > > > The Yaws arg seems to have lots of unused fields that get carried
> > > > around inside Erlyweb.
>
> > > > Using an ErlyWeb record that is adapted from a filtered version of the
> > > > Yaws arg would help isolate future modifications to the adapter code
> > > > when Yaws arg changes.
>
> > > > Also, adapters could be made to support other web servers.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| rsaccon |
| Posted: Mon Nov 12, 2007 12:59 pm |
|
|
|
User
Joined: 09 Aug 2006
Posts: 144
|
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 <robi...@gmail.com> 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 erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
 
|
| Guest |
| Posted: Mon Nov 12, 2007 9:10 pm |
|
|
|
Guest
|
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 <robi...@gmail.com> 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 erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Nov 13, 2007 3:57 am |
|
|
|
Guest
|
Werl (Wsgi for ERLang) like the magical Smerl
Wack like Rack which is a clean Ruby WSGI:
http://rack.rubyforge.org/
On Nov 12, 3:31 pm, Roberto Saccon <rsac...@gmail.com> wrote:
> Name suggestions: erlwgate, gaterl, werlgate, uniweb, erlywebunify or
> a greek god as fantasy name.
>
> Roberto
>
> On Nov 12, 7:09 pm, Filippo Pacini <filippo.pac...@gmail.com> 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 <robi...@gmail.com> 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 erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Nov 13, 2007 4:48 am |
|
|
|
Guest
|
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 <filippo.pacini@gmail.com> 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 <robi...@gmail.com> 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 erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Nov 13, 2007 5:40 am |
|
|
|
Guest
|
All three servers use an out(Request) style callback interface. You
could just make accessor functions that get at the different useful
bits of info in the request data structure, and a function to do the
return. When I used Yaws I had functions like this anyway because I
hated the compile time dependency of the .hrl file and record layout.
There's three "big" differences between mochiweb and yaws or iserve:
* mochiweb doesn't spawn a process for each request, it uses the same
process as the one that has the TCP socket.
* mochiweb uses a parameterized module instead of a record (though
the layout of a parameterized module looks somewhat like a record).
* mochiweb doesn't use the return value of the callback, you need to
explicitly call a function to render the HTTP request (you can even
write directly to the socket if you wanted to, which is why it's
designed this way).
It's of course easy to write a wrapper that makes mochiweb look like
iserve or yaws, because it works at a lower level and doesn't really
make any assumptions (more like a library than a framework).
I really don't think that the connector should accept anything but
tuple of return code, headers (as a proplist), and iodata for the
response... anything else would depend on functionality that doesn't
exist in iserve or mochiweb.
-bob
On 11/12/07, Yariv Sadan <yarivsadan@gmail.com> wrote:
>
> 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 <filippo.pacini@gmail.com> 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 <robi...@gmail.com> 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 erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| rsaccon |
| Posted: Tue Nov 13, 2007 10:10 am |
|
|
|
User
Joined: 09 Aug 2006
Posts: 144
|
Name suggestions: erlwgate, gaterl, werlgate, uniweb, erlywebunify or
a greek god as fantasy name.
Roberto
On Nov 12, 7:09 pm, Filippo Pacini <filippo.pac...@gmail.com> 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 <robi...@gmail.com> 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 erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Nov 13, 2007 10:54 am |
|
|
|
Guest
|
Off the top of my head:
ewgi (pronounced eww-gee): Erlang Web Gateway Interface
ewai (pronounced eww-i): Erlang Web App Interface
ewsi (pronounced eww-see): Erlang Web Server Interface
--Kevin
On Nov 12, 2007 10:57 PM, Robin <robi123@gmail.com> wrote:
>
> Werl (Wsgi for ERLang) like the magical Smerl
> Wack like Rack which is a clean Ruby WSGI:
>
> http://rack.rubyforge.org/
>
>
>
>
> On Nov 12, 3:31 pm, Roberto Saccon <rsac...@gmail.com> wrote:
> > Name suggestions: erlwgate, gaterl, werlgate, uniweb, erlywebunify or
> > a greek god as fantasy name.
> >
> > Roberto
> >
> > On Nov 12, 7:09 pm, Filippo Pacini <filippo.pac...@gmail.com> 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 <robi...@gmail.com> 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 erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Nov 13, 2007 10:56 pm |
|
|
|
Guest
|
An example of yaws gateway might look like this (not working code, just
a sketch of the interface  ):
-module(yawsgw, [Appl]).
-export([out/1]).
-export([setup_environ/1,
start_response/2,
run/1,
write/1,
end_response/0
]).
%% this is neded to run as a yaws appmod
out(Arg) ->
run(Arg).
run(Arg) ->
Env = setup_environ(Arg),
Result = Appl:handle_req(Env, fun start_response/2),
write(Result).
setup_environ(YawsArg) ->
%% parse yaws arg and transform
YawsArg.
start_response(["200"|_Rest], Headers) ->
Headers;
start_response(Status, Headers) ->
[{status, Status}, Headers].
write(Result) ->
Result.
end_response() ->
void.
Then the erlyweb adaptor would be something like:
handle_req(Env, StartResp) ->
StartResp(out(Env, app_name(Env), req_str(Env)
out(A, AppName, ReqStr) -> Response.
IMHO Env should be a proplist containing all the http request data (e.g.
host name, query string, method, etc...) then we could add a list of
server specific values (e.g. the opaque for yaws) and group them inside Env.
In defining the interface above I followed the python wsgi api. I don't
know if this is general enough and if it fits well in erlang. I'll try
to write some hello world examples with yaws and mochiweb in the weekend.
Yariv Sadan wrote:
> 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 <filippo.pacini@gmail.com> 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.
>>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Nov 13, 2007 10:59 pm |
|
|
|
Guest
|
Thanks for all the name suggestion and for the rack link. I didn't know
of it.
filippo
Kevin Smith wrote:
> Off the top of my head:
>
> ewgi (pronounced eww-gee): Erlang Web Gateway Interface
> ewai (pronounced eww-i): Erlang Web App Interface
> ewsi (pronounced eww-see): Erlang Web Server Interface
>
> --Kevin
>
> On Nov 12, 2007 10:57 PM, Robin <robi123@gmail.com> wrote:
>> Werl (Wsgi for ERLang) like the magical Smerl
>> Wack like Rack which is a clean Ruby WSGI:
>>
>> http://rack.rubyforge.org/
>>
>>
>>
>>
>> On Nov 12, 3:31 pm, Roberto Saccon <rsac...@gmail.com> wrote:
>>> Name suggestions: erlwgate, gaterl, werlgate, uniweb, erlywebunify or
>>> a greek god as fantasy name.
>>>
>>> Roberto
>>>
>>> On Nov 12, 7:09 pm, Filippo Pacini <filippo.pac...@gmail.com> 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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Nov 14, 2007 7:10 am |
|
|
|
Guest
|
On 11/13/07, Yariv Sadan <yarivsadan@gmail.com> wrote:
>
> On Nov 12, 2007 9:40 PM, Bob Ippolito <bob@redivi.com> wrote:
> >
> > All three servers use an out(Request) style callback interface. You
> > could just make accessor functions that get at the different useful
> > bits of info in the request data structure, and a function to do the
> > return. When I used Yaws I had functions like this anyway because I
> > hated the compile time dependency of the .hrl file and record layout.
>
> Yeah, I hate it too. That's why ErlyWeb comes with the yaws_arg module
> (which is still a PITA because it occasionally breaks with new
> versions of Yaws). I agree that a generic record type would be better.
The solution is to not use records in the API (as anything but opaque
data handles), not to use a generic record type
> >
> > There's three "big" differences between mochiweb and yaws or iserve:
> >
> > * mochiweb doesn't spawn a process for each request, it uses the same
> > process as the one that has the TCP socket.
>
> Why does it not spawn a new process for each request? I think that
> most apps would benefit from handling multiple requests concurrently.
> Is it that MochiWeb expects that application handler to implement its
> own concurrency? If so, I would suggest adding an option for MochiWeb
> to run in concurrent mode. Is this planned by any chance?
You've misunderstood me, IIRC Yaws spawns two processes for each HTTP
request, one for the socket and one for the appmod (or maybe you only
need to do that when streaming, but it's still necessary under some
condition). mochiweb spawns one process that both the socket and the
application code runs in, and you have full capabilities in that one
process, even to switch protocols (since the socket is yours). It's of
course assumed that you're using at least one process per TCP socket,
otherwise WTF are you using Erlang for
> > * mochiweb uses a parameterized module instead of a record (though
> > the layout of a parameterized module looks somewhat like a record).
> > * mochiweb doesn't use the return value of the callback, you need to
> > explicitly call a function to render the HTTP request (you can even
> > write directly to the socket if you wanted to, which is why it's
> > designed this way).
> >
> > It's of course easy to write a wrapper that makes mochiweb look like
> > iserve or yaws, because it works at a lower level and doesn't really
> > make any assumptions (more like a library than a framework).
> >
> > I really don't think that the connector should accept anything but
> > tuple of return code, headers (as a proplist), and iodata for the
> > response... anything else would depend on functionality that doesn't
> > exist in iserve or mochiweb.
>
> Fair enough. I think it would be useful, perhaps as a utility, to have
> a module that translates Yaws appmod return values to MochiWeb "raw"
> responses values to ease migration for existing Yaws apps, but it
> doesn't strictly have to be part of the connector.
mochiweb's "raw" response values are iodata like they should be, it
has to turn into that form eventually anyway, and the code to convert
from yaws expressions to binary should really be a library function
rather than a framework convention anyway... converting tuples to html
is orthogonal to web serving.
-bob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Nov 14, 2007 7:44 am |
|
|
|
Guest
|
>
> The solution is to not use records in the API (as anything but opaque
> data handles), not to use a generic record type
I agree - I should have phrased it better.
>
> > >
> > > There's three "big" differences between mochiweb and yaws or iserve:
> > >
> > > * mochiweb doesn't spawn a process for each request, it uses the same
> > > process as the one that has the TCP socket.
> >
> > Why does it not spawn a new process for each request? I think that
> > most apps would benefit from handling multiple requests concurrently.
> > Is it that MochiWeb expects that application handler to implement its
> > own concurrency? If so, I would suggest adding an option for MochiWeb
> > to run in concurrent mode. Is this planned by any chance?
>
> You've misunderstood me, IIRC Yaws spawns two processes for each HTTP
> request, one for the socket and one for the appmod (or maybe you only
> need to do that when streaming, but it's still necessary under some
> condition). mochiweb spawns one process that both the socket and the
> application code runs in, and you have full capabilities in that one
> process, even to switch protocols (since the socket is yours). It's of
> course assumed that you're using at least one process per TCP socket,
> otherwise WTF are you using Erlang for
Hehe... I was quite confused when I read your message.. "A single
threaded Erlang server? He must be joking... "
I wasn't aware that Yaws spawns 2 processes per request... Maybe only
for multipart requests? This would be worth clarifying on the Yaws
list.
>
> > > * mochiweb uses a parameterized module instead of a record (though
> > > the layout of a parameterized module looks somewhat like a record).
> > > * mochiweb doesn't use the return value of the callback, you need to
> > > explicitly call a function to render the HTTP request (you can even
> > > write directly to the socket if you wanted to, which is why it's
> > > designed this way).
> > >
> > > It's of course easy to write a wrapper that makes mochiweb look like
> > > iserve or yaws, because it works at a lower level and doesn't really
> > > make any assumptions (more like a library than a framework).
> > >
> > > I really don't think that the connector should accept anything but
> > > tuple of return code, headers (as a proplist), and iodata for the
> > > response... anything else would depend on functionality that doesn't
> > > exist in iserve or mochiweb.
> >
> > Fair enough. I think it would be useful, perhaps as a utility, to have
> > a module that translates Yaws appmod return values to MochiWeb "raw"
> > responses values to ease migration for existing Yaws apps, but it
> > doesn't strictly have to be part of the connector.
>
> mochiweb's "raw" response values are iodata like they should be, it
> has to turn into that form eventually anyway, and the code to convert
> from yaws expressions to binary should really be a library function
> rather than a framework convention anyway... converting tuples to html
> is orthogonal to web serving.
>
> -bob
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Nov 14, 2007 9:29 pm |
|
|
|
Guest
|
On Nov 12, 2007 9:40 PM, Bob Ippolito <bob@redivi.com> wrote:
>
> All three servers use an out(Request) style callback interface. You
> could just make accessor functions that get at the different useful
> bits of info in the request data structure, and a function to do the
> return. When I used Yaws I had functions like this anyway because I
> hated the compile time dependency of the .hrl file and record layout.
Yeah, I hate it too. That's why ErlyWeb comes with the yaws_arg module
(which is still a PITA because it occasionally breaks with new
versions of Yaws). I agree that a generic record type would be better.
>
> There's three "big" differences between mochiweb and yaws or iserve:
>
> * mochiweb doesn't spawn a process for each request, it uses the same
> process as the one that has the TCP socket.
Why does it not spawn a new process for each request? I think that
most apps would benefit from handling multiple requests concurrently.
Is it that MochiWeb expects that application handler to implement its
own concurrency? If so, I would suggest adding an option for MochiWeb
to run in concurrent mode. Is this planned by any chance?
> * mochiweb uses a parameterized module instead of a record (though
> the layout of a parameterized module looks somewhat like a record).
> * mochiweb doesn't use the return value of the callback, you need to
> explicitly call a function to render the HTTP request (you can even
> write directly to the socket if you wanted to, which is why it's
> designed this way).
>
> It's of course easy to write a wrapper that makes mochiweb look like
> iserve or yaws, because it works at a lower level and doesn't really
> make any assumptions (more like a library than a framework).
>
> I really don't think that the connector should accept anything but
> tuple of return code, headers (as a proplist), and iodata for the
> response... anything else would depend on functionality that doesn't
> exist in iserve or mochiweb.
Fair enough. I think it would be useful, perhaps as a utility, to have
a module that translates Yaws appmod return values to MochiWeb "raw"
responses values to ease migration for existing Yaws apps, but it
doesn't strictly have to be part of the connector.
Yariv
>
> -bob
>
>
> On 11/12/07, Yariv Sadan <yarivsadan@gmail.com> wrote:
> >
> > 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 <filippo.pacini@gmail.com> 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 <robi...@gmail.com> 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 erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
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 cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
