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
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
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.