> > 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 [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 -~----------~----~----~----~------~----~------~--~---
