> I would vote for 'Applications' being a dictionary that maps the name of
> the app to it's home directory. The name is what you would see in the URI.
> That's almost what contexts are now.
> >and the names of the config files could be implied by the names of the
> >applications. We could take it one step further, and look for a class in the
> Yes, if/when we switch to this approach, we would grab "Application.config"
> out of the home dir of the app, overlay on the default WebKit
> Application.config and proceed.
> >Application's root folder named after that application, ie MyApp.py
> >containing a class called MyApp would be automatically loaded and used. If
> >it didn't exist, it would fall back on the generic Application class.
> My preference is to name the directory MyApp and then name the classes
> generically: Application.py, Session.py, etc. One advantage is that you
> only have to change the directory name to change the app name. Another is
> that you can copy (or link to) a file without having to modify it (although
> there are better ways to structure your reuse). And you'll also instantly
> recognize the classes when you examine someone else's app.
Perhaps a cleaner approach would be to define a directory hierarchy that
would be assumed. So you would have the root directory of your
Context/Application(I'm still stuck on that term), and beneath it, you
might have at least three directories, Config (any config files),
Classes (Session, Application/Context, etc), Content or Servlets
(obvious). More elaborate sites might have a Cans directory, a Static
> >What would be the changes required to the internals of the WebKit to do
> >this? Things that spring to mind are:
> >- parsing the URI to determine which application should handle the request
> I would do that in the adapter which would then send the raw request to the
> application which would have it's own port.
Then what's the difference from running multiple AppServers? That's
essentially what you're saying here. The only difference being you only
have one directory for WebKit. In that case, we could just modify
AppServer to take a command line telling it which set of configuration
files to use.
> >- should the cache be per-Application, or for the entire server?
> per-Application (since I picture the app being a single process in it's own
> >- some of the functionality in Application seems to be generic in that it
> >would be redundant to have multiple instances of Applications doing it
> >(error-checking URLs and so forth), so it would probably be best to move it
> >someplace else (ApplicationManager? ApplicationFactory?)
> Seems like these things have to be done per request that comes in. It's
> really the code that needs to be reused. I would leave it in application.
> >- would this obsolete the need for contexts? even if so, would it really be
> >worth removing them from the code? :)
> Yes and if the new design was clean enough, then yes again.
I was intending to extend the Context concept to something like this.
But Chuck and I have always differed on where to split the line between
AppServer, Application and Context. (Well, I don't know that we differ
that much, we've just never reconciled our terminology ;) ) If you're
going to run on Multiple ports, I think you're splitting too high.