Hello Ian, first of all, sorry for a bit too long pause.
Friday, April 05, 2002, 3:30:43, you wrote: IB> I'm not sure... I couldn't completely follow your description, but it IB> doesn't seem to address most of the problems from what I could tell. IB> For instance, it doesn't address having a URL reference an object that IB> is not attached to a file, and I'm not sure how you might allows new IB> logic to be plugged into certain parts of the path. Or automatic IB> directories, spell checking... I'm not sure what all else. There's a IB> lot of things to keep in mind. i see it the way vfs works (or rather the way i believe it works) - there is some root 'fs' set up when webkit is installed, something like a lines in app.config file pointing to files with class URLSpRoot(URLSpaceHandler): class VirtualSpRoot(VirtualSpaceHandler): class PhisSpRoot(PhisicalSpaceHandler): the way other parts of path are plugged-in will be dependant on implementations of those - it could be unpluggable, subpath handlers could be defined in context wide classes (in __init__.py or something like that), i see the typical processing of the request like this: user requests http url subdomain.domain/path/subpath/ URLSpRoot looks at the domain part of the url first, let's pretend that it has no special meaning to it that it looks at the 'subdomain' part sees that it's one the 'debug' domains, checks that connecting peer has debugging rights (test passes) and sets 'debug' flag in the request, then it looks at the some config vars and sees that contexts are disabled so it just starts traversing the root 'folder' (note we are still talking about ulr folders) - it checks if this 'folder' was checked for special options (how it does depends on the handler - it could look for some file in /wkit/urloptions/path/ or extract those data from the folder name or whatever), if it was and it not yet time to recheck it behaves the way those options tell it to. i out case let them tell the handler that it should pass control to another handler (that url handler is specified in virtual space - for now let's suppose we just have it) - that handler is a user-defined handler --- Note: when handler passes control to another one - it should tell what part of url is already processed - how it does that is to be decided upon implementation. --- that handler just deepens thru the rest of the url checking at each dir that the corresponding virtual space 'folder' exists - if it does not - it lists all available subfolders (VirtulaSpaceHandler should provide such hooks when possible) and chooses one lexicographicaly closest (or checks the spelling if you want). after all this we get some 'path' in Virtual space - something like 'path.subsaph' for instance virtual space handler heaves pretty much like URLspace handler it traverses the 'path' passing control to other vspace handlers as needed - the final aim of this is to get a name of some factory class and parameters for it (note that it is as well specified in virtual space (at least, i believe it should)) then this factory is checked to produce Servlet (how? not sure) then we run it and get the response to send to client. factories could be - cgiFactory, classicServletFactory, rawFileFactory, mod_python-likeFactory, functionFactory (this could look for specific functions in the .py for extra-simple servlets), errorMessageFactory and who-knows-what-else-Factory. physical space handlers are not all THAT needed - but i believe that most content will be file-system served anyway and another layer of abstraction could be only a good thing - that we can serve data from zodb (if we want to, sure), or it could help you clean up you dirs - so if requested for .css files it could loook in /styles subdir, of when some file doesn't exist look in '_inherit' folders of parent folders. you should see by now that such system provides us with unlimited and unprecedented possibilities for.. well, anything. IB> Well, I won't speak to MK, but the debugging problem is a significant IB> one. However, it's also very subtle. I tried doing something for this, IB> and got fairly far along before I realized what I was doing wasn't going IB> to fix anything. IB> The biggest problem in what I tried was that reloading modules isn't IB> enough: you will still have stale objects and classes that came from the IB> old module. The servlet cache can eliminate the first level of these, IB> but it's much more challenging to eliminate more of them. IB> It's solvable, I'm sure, but harder than you might originally expect. well, this came by cause oneshot is too slow for my machine. and i REALLY don't want my users to see tracebacks even if error occurs. anyone else is interested? -- Serge Shchetinin a.k.a. Maluke. 8.Apr.2002 _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
