Hello people, sorry if these issues were discussed before, but i see no trace of them being implemented so i assume they were not.
i was thinking what a decent (imho sure) appserver needs to have and here are the results: 3-domains: i think it's a nice feature to have: imagine that there are 3 levels of abstraction that are as follows: address space (there are actually should be as many address spaces as there are protocols), virtual space (this is a space, servlets operate in) and physical space. So if the url prot://domain/path/dir is called, Application looks for an address space (AS) handler for a protocol 'prot' that handler looks at a domain name and decides what AS handler will be used on it that handler in turn looks at the path (it probably should be informed that the protocol and domain parts are already processed) and decides what virtual space handler should be used on it (or direct processing of the AS name further to other handlers), virtual space (VS) name is to look something like 'foo.bar.name', here it's processed in a similar way and in the end is transformed into a file name plus in a case of a servlet a class name (that has to be implemented in that file), then a logic similar to the one present i nwebkit now comes to play. this gives us many advantages. we can easily implement an (incredibly flexible) aquisition (for people who want it) in a virtual space (that's a lot different from zope-way (russian speakers know what i'm talking about) aquisition that exposes all the guts of the application), we can easily control what is published and what is not, we can allow for a much more custom handling of requests (things that are done with extrapathinfo could be done in a more natural way), there could be as many servlets per file as desired, you can simply implement virtual hosting and things like that, there are some benefits for caching (same servlet on multiple urls) and more things i can't remember, and it's 100% backwards compatible! middlekit: why not to save a model that was used to generate sql and .py stubs? if we do we can see what changes were made since last generation and generate an 'alter' statements in sql instead of dropping and recreating tables (we can fill new fields of old records with default values specified in a dedicated column or NULLs if none are specified and NULL is permitted). this would enable us to alter models of production phase sites and abandon Samples.csv files. debugging: there should be hooks for a programmer to determine if the servlet is used in debug mode (so 'user' determines it and webkit uses that info) and proceed in some way like this: if debugging reload all changed modules; if failed (unhandled exception in servlet): and debugging generate tracebacks and display them, else just send traceback to webmaster and show some error message to user without exposing any source and whatever else. debugging mode should be possible to set explicitly, or be detected by the host of the client (localhost is likely to be debugging) and by custom logic. and then after deployment debug mode could be locked out completely. i believe you should see the idea by this time. i hope all of this is not completely stupid and some comments will follow. regards -- Serge Shchetinin a.k.a. Maluke. 3.Apr.2002 _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
