From: Chuck E. <ec...@mi...> - 2000-08-21 03:00:26
|
At 10:39 PM 8/20/00 -0400, Daniel Green wrote: >Is the possibility of supporting multiple applications out of the question? Not at all. This was part of my original mental design, but something that I haven't gotten to yet. It's also the design used by WebObjects and a very appropriate one in my opinion. More below: >This would simplify a number of things. > >For example, AppServer.config would now look something like: >{ > 'PrintConfigAtStartUp': 1, > 'Verbose': 1, > 'Host': '127.0.0.1', > 'Port': 8086, > 'PlugIns': [], > 'PlugInDirs': ['..'], > 'ServerThreads': 10, > 'Applications' : { > 'MyApp' : 'MyApp.config', > 'MyOtherApp' : 'MyOtherApp.config' > } >} > >Application configuration stuff would be done in the specified files, rather >than just one configuration for the entire server. Alternatively, it could >even just be: > >'Applications': [ 'MyApp', 'MyOtherApp' ] 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. >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. >- 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 right). >- 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 have yet to get a firm grasp on all the internals of the WebKit thus far, >so feel free to throw stuff at me and boo me off stage if I'm totally off >base. :) You're very much on base and obviously have a good handle on this stuff. >As far as plug-ins go, I guess that since Python doesn't have private >members of classes, plug-ins pretty much have free reign to do what they >want, making them effectively unlimited in function. Am I right? That is correct. You can add methods to classes, mix in base classes, etc. However, all the stuff you described above would be WebKit specific, but then you're probably alluding to the other things we talked about. Also, I think each application should be a separate process. After all, GUI apps don't share the same process space right? Let each application deal with it's own leaks, hang ups, deadlocks, port problems, etc. -Chuck |