9 ms·

The Rails team has thought a lot about the stateless nature of HTTP requests, and they've pushed for a RESTful style of handling things (e.g., the REST architec

The Rails team has thought a lot about the stateless nature of HTTP requests, and they've pushed for a RESTful style of handling things (e.g., the REST architecture described in O'Reilly "RESTful Web Services" book). Seaside (and Weblocks) seem to focus on continuations, but I'm not convinced this is the way to go, particularly with richer Ajax and Flex clients. Ezra Z has made Merb, a lighter and arguably cleaner version of core Rails (minus AR, etc), if you're bugged by Rails core code.

omouse 19y ago
but I'm not convinced this is the way to go, particularly with richer Ajax and Flex clients. Could you shed a little light on why you feel that way?
- DocSavage 19y ago
  If you have a very simple app that maps well to CRUD, a REST approach might be all you need. In that case, things are quite simple and scalable on the server side. If you are building an Ajax/Flex rich client, particularly one that can work offline, you'd want the state on the client-side. Then you could view the server in a very RESTful way while handling program flow in your client app. Under these circumstances, there's less of a win with continuations. Among the advantages in imposing a RESTful architecture on your server, the most interesting to me is the way that your server becomes a bunch of resources on which you can do a very limited set of things (the HTTP verbs). It imposes an easily understood interface, which is nice if you (or others) write other apps to access your server.
LogicHoleFlaw 19y ago
Oh definitely. I didn't mean to imply that the Rails team hasn't thought about things like REST. They are huge proponents of that design philosophy. One of the big advantages of statelessness is that it scales wonderfully. REST aligns itself with HTTP very nicely. Continuations are a clever compromise between highly stateful applications and stateless HTTP. Ajax and Flex turn your browser into a smart client of sorts, and I think that a RESTful service design can stand independent of any particular client. It allows for many different clients to interact with your service besides just your particular Ajax web page. In that sense continuations would be perfectly suitable in those situations where you need to keep track of state. RESTful services need to stand independent of a particular client front end. Anyway, I think that those principles are complementary and should work well together. Ajax (or some other rich client technology) on the front end and REST on the back. Hmm. I think I may try my hand at writing a small web framework in Lua... that's been kicking around in my head lately.
- pstuart 19y ago
  Lua has been on my "todo" list for a while. Looks like there's already a framework out there: http://www.keplerproject.org http://www.keplerproject.org

omouse 19y ago

but I'm not convinced this is the way to go, particularly with richer Ajax and Flex clients. Could you shed a little light on why you feel that way?

DocSavage 19y ago
If you have a very simple app that maps well to CRUD, a REST approach might be all you need. In that case, things are quite simple and scalable on the server side. If you are building an Ajax/Flex rich client, particularly one that can work offline, you'd want the state on the client-side. Then you could view the server in a very RESTful way while handling program flow in your client app. Under these circumstances, there's less of a win with continuations. Among the advantages in imposing a RESTful architecture on your server, the most interesting to me is the way that your server becomes a bunch of resources on which you can do a very limited set of things (the HTTP verbs). It imposes an easily understood interface, which is nice if you (or others) write other apps to access your server.

LogicHoleFlaw 19y ago

Oh definitely. I didn't mean to imply that the Rails team hasn't thought about things like REST. They are huge proponents of that design philosophy. One of the big advantages of statelessness is that it scales wonderfully. REST aligns itself with HTTP very nicely. Continuations are a clever compromise between highly stateful applications and stateless HTTP. Ajax and Flex turn your browser into a smart client of sorts, and I think that a RESTful service design can stand independent of any particular client. It allows for many different clients to interact with your service besides just your particular Ajax web page. In that sense continuations would be perfectly suitable in those situations where you need to keep track of state. RESTful services need to stand independent of a particular client front end. Anyway, I think that those principles are complementary and should work well together. Ajax (or some other rich client technology) on the front end and REST on the back. Hmm. I think I may try my hand at writing a small web framework in Lua... that's been kicking around in my head lately.

pstuart 19y ago
Lua has been on my "todo" list for a while. Looks like there's already a framework out there: http://www.keplerproject.org http://www.keplerproject.org