Web app thoughts
Posted: Tue Oct 19, 2010 10:38 am
As I mentioned before, I've done a little bit of work in this area, but I never get very far due to being busy with the compiler and other things. Below are my thoughts on creating a web application server in Cobra.
Well instead of all this work, maybe we just need some nice tutorials on using things like:
-- Mac or Linux + Mono + Cobra + Castle Monorail
-- Windows + .NET + Cobra + Castle Monorail
But if we build a new one, I was picturing an application server that hid behind a web server such as Apache or lighttpd. Communication would be via SCGI which I believe is the "current way to do things". We have an open source Cobra SCGI library at http://bitbucket.org/webnov8/overlap/wiki/Home
It's useful for an app server to have an option to serve HTTP for development and quick setup. But generally it would not be mature enough to put into production.
The above arrangement matches other projects including Webware for Python (which I founded) and Django (the most popular web app server in the Python community at this time).
Some additional random bits:
-- Especially during development, it is useful to have the app server "restart" or "reload" when code files changed. The standard library can already watch the file system and a build command could be issued by convention and/or configuration. That leaves the reloading part. I investigated using .NET app domains to reload code that had changed, but ran into some issues at least on Mono. Consequently, my plan became to use the Webware approach where the entire app server exits with exit code 3 in such cases and a wrapper script restarts it based on that. See the "while" loop at the bottom of http://svn.w4py.org/Webware/trunk/WebKit/AppServer. In practice this works great.
-- The treatment that web browsers give to relative URLs like <a href="foo"> is sensitive to whether the current url ends in / or not: http://example.com/baz vs. http://example.com/baz/. An app server could support both URLs in which case the links in your page will need to adapt to the two cases, which generally means putting them through a function. Alternatively, the app server can always redirect to the URL ending in / for consistency in which you always know what to expect. Django does this and I think it works well.
-- For each page, I prefer to use a class (like Webware) rather than a method (like Rails). I then use inheritance to get access to utility methods and other goodies.
-- I'm all for a command line tool like Django and Rails that is used to kick off a directory and do other things, but it should not be through the Cobra compiler.
-- I was thinking that the app server would not dictate anything about storage. Instead, the developer would use whatever they like such as NHibernate, Castle ActiveRecord, the repository pattern, Subsonic, MongoDB, etc.
-- I'm also influenced by the Pylons approach where you can mix and match pieces.
-- The project should have its own name and be hosted somewhere like Google Code or Bitbucket.
-- Of course, if you develop an app server, these things will be up to your discretion.
HTH
Well instead of all this work, maybe we just need some nice tutorials on using things like:
-- Mac or Linux + Mono + Cobra + Castle Monorail
-- Windows + .NET + Cobra + Castle Monorail
But if we build a new one, I was picturing an application server that hid behind a web server such as Apache or lighttpd. Communication would be via SCGI which I believe is the "current way to do things". We have an open source Cobra SCGI library at http://bitbucket.org/webnov8/overlap/wiki/Home
It's useful for an app server to have an option to serve HTTP for development and quick setup. But generally it would not be mature enough to put into production.
The above arrangement matches other projects including Webware for Python (which I founded) and Django (the most popular web app server in the Python community at this time).
Some additional random bits:
-- Especially during development, it is useful to have the app server "restart" or "reload" when code files changed. The standard library can already watch the file system and a build command could be issued by convention and/or configuration. That leaves the reloading part. I investigated using .NET app domains to reload code that had changed, but ran into some issues at least on Mono. Consequently, my plan became to use the Webware approach where the entire app server exits with exit code 3 in such cases and a wrapper script restarts it based on that. See the "while" loop at the bottom of http://svn.w4py.org/Webware/trunk/WebKit/AppServer. In practice this works great.
-- The treatment that web browsers give to relative URLs like <a href="foo"> is sensitive to whether the current url ends in / or not: http://example.com/baz vs. http://example.com/baz/. An app server could support both URLs in which case the links in your page will need to adapt to the two cases, which generally means putting them through a function. Alternatively, the app server can always redirect to the URL ending in / for consistency in which you always know what to expect. Django does this and I think it works well.
-- For each page, I prefer to use a class (like Webware) rather than a method (like Rails). I then use inheritance to get access to utility methods and other goodies.
-- I'm all for a command line tool like Django and Rails that is used to kick off a directory and do other things, but it should not be through the Cobra compiler.
-- I was thinking that the app server would not dictate anything about storage. Instead, the developer would use whatever they like such as NHibernate, Castle ActiveRecord, the repository pattern, Subsonic, MongoDB, etc.
-- I'm also influenced by the Pylons approach where you can mix and match pieces.
-- The project should have its own name and be hosted somewhere like Google Code or Bitbucket.
-- Of course, if you develop an app server, these things will be up to your discretion.
HTH