On 11/13/07, Yariv Sadan <[EMAIL PROTECTED]> wrote: > > On Nov 12, 2007 9:40 PM, Bob Ippolito <[EMAIL PROTECTED]> 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 [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 -~----------~----~----~----~------~----~------~--~---
