At 06:17 PM 11/1/2001 -0800, Tavis Rudd wrote:
>My argument isn't to do with what's provided, but rather who is
>responsible for providing it. It would make more sense to me for the
>component to install some docs to a central Webware location when its
>setup.py is run. That way no assumptions are needed about the
>structure of the component. This is essentially what goes on with
>the docs in Python standard library. When a module or package is
>added to the Python library all relevant documentation is added to
>the Python-x.x/Doc directory. The onus is on the component
>to play nicely with Webware, rather than on Webware to play nicely
>with the component.
But then the docs get buried if we allow components to squirrel them away
where ever they want. Being able to go to SomeKit/Docs/ is very much
intentional. And I don't see asking package writers to put their docs in
"Docs/" to be a burden. Are you bothered that you can't put them in
"documentation/" or put the .tex files in the same dir as the .py files?
>Oh, I was definitely thinking of each component being structured as a
>Python package. The rest was just thinking aloud:
>
>* make AppServer and Application a little more generic by stripping
>all the 'launch' behaviour out of them and putting it in the
>launcher script --- exactly what I've done in Launcher.py in the
>redesign code. AppServer and Application should only be responsible
>for handling requests, etc. the loading of config settings, plugins,
>etc. should all be handled by the launcher.
I'm guessing only AppServer has the "launch behavior" you refer to. In any
case, I don't see this as a big deal either way. Even if I agreed, and I
don't know that I do, this is sooooo low on my list compared to things like
working-nicely-with-WingIDE and url-decoding.
>* the launcher should control where components are loaded from. To
>facilitate this I'd make a Plugin class that components would
>subclass. The constructor would accept the AppServer instance as an
>arg and do whatever it wants with it. The component's plugin
>subclass would be loaded by the launcher. The launcher would expect
>the components to be in a particular place and have particular
>structure, BUT the AppServer wouldn't. This makes it easy to
>customize the launch procedure.
>
>At the moment AppServer is creating an instance of PlugIn from the
>path of the component. This is backwards! The plugin should be in
>control, not the AppServer. Speaking in terms of a sentence, the
>AppServer is the object, not the subject.
>
>Launcher -->> Plugin -->> AppServer
I still don't see the follow-on as in "this is important so that component
developers can..." or "this allows web site developers to..."
And you're back to a plug-in class. Plug-ins are just packages. No specific
plug-in class is required or necessary as far as I can tell. Perhaps it is
in your architecture where a plug-in is sandwiched between a launcher and
the app server and the app server is just a plug-in. Well no, even there
the AppServer's __init__.py should be able to TCOB, yes?
But frankly, I don't see why anyone would care.
>* the launcher script should also handle the monitoring behaviour and
>launching a non-persistent version of the AppServer. See the
>attached module.
Again, I'm not biting my nails over the fact that AppServer handles
plug-ins and monitoring.
> > The Launcher.py script is a lightweight bootstrapper that solves
> > some of the subtle issues of Python imports, paths, etc. I'd
> > prefer to keep it lightweight (just 60 lines) and continue to focus
> > on AppServer and Application as we always have in the past.
>
>This seems to be at odds with your philosophy of not making WebKit
>monolithic, with which I agree. As Terrel has written before,
>AppServer and Application are already too large for their own good.
>Some refactory feels necessary here. We've adopted the unit testing
>and wiki aspects of ExtremeProgramming so why not the 'aggresive
>refactoring'? ;-)
Because I'm not seeing that component developers or web site developers are
being hampered. I don't have the motivation in this area that I do in some
of the other areas I discussed recently.
>At the moment AppServer and Application are doing things that they
>shouldn't be responsible for. Here's how I see WebKit working:
That's a matter of opinion. Of course, that might be a silly, obvious
statement on my part. :-)
>Launcher -- is responsible for all startup stuff. It reads the
> config files then loads the various pieces of the
> system with the settings from those files and puts
> them together. pieces = Dispatcher, AppServer,
> Application(s), Plugins, etc.
My thought was that the application server is what has a configuration and
what has plug-ins. You may or may not convince me on plug-ins. You probably
won't convince me on configuration: If the app server ever says
self.setting('foo') then I expect 'foo' to be in AppServer.config. I'm not
about to obfuscate the relationship between settings and config files if I
can help it.
>---------------------------------------------------------------------------------------------------
Why do you put these huge lines of dashes in your e-mails? They always wrap
and look strange.
> > >What do other people think about this? My dislike of it
> > > primarilly stems from 'MiscUtils' and 'WebUtils'. If the are
> > > going to be top-level packages they should have names that
> > > clearly identify them as part of Webware.
> >
> > What clearly identifies MiddleKit and UserKit as being part of
> > Webware any more than *Utils?
>
>Nothing really, but they're unique names not likely to be used
>anywhere else.
No one else is using the names, MiscUtils and WebUtils.
I anticipate that I could use MiscUtils in future open source projects
outside of Webware, in which case I will facilitate the release of
standalone versions of these. They are catch-alls because we need catch
alls and because it encourages us to refrain from carelessly tying these
classes and functions into WebKit such that they can't be used independently.
They're here to stay.
> > >If people in Geoff's company are using it maybe the discussion
> > > should be about whether it should be used for SessionStore. My
> > > argument isn't that it's not usefull, but that it's not
> > > appropriate for SessionStore.
> >
> > So now for the next step:
> > Why is it not useful and not appropriate?
>
>I'm not making any statement about whether it's useful, because I
>haven't used it. It's not a appropriate for SessionStore because it
>makes that piece of logic more complex rather than simplifying it,
>and it's slower than just using a session manager thread that is
>owned by the SessionStore itself.
I'd like to hear from others (Geoff, Jay, Tom?) if there are any
advantages. Again, I'm not strongly opinionated on this one although I'm
curious about the speed differences, as in, where do they come from?
You don't necessarily have to answer that. I should read the code.
> > > > You already have:
> > > >
> > > > - the ability to dictate what plug-ins are loaded or not loaded
> > > > via WebKit/Configs/AppServer.config
> > >
> > >But the loading procedure is handled by the AppServer and assumes
> > > a particular directory structure. My argument is that the
> > > launcher script is a more natural place to load the plugins from.
> >
> > The directory locations for plug-ins are NOT assumed. They are read
> > from AppServer.config. It's true that the out-of-the-box config
> > looks in Webware/, but then what did you expect?
> >
> > If you want the plug-ins from somewhere else, tweak
> > AppServer.config and you're done. I can't make it any easier than
> > that.
>
>But, don't they all have to come from single dir? What happens when
>you have plugins coming from several physical locations?
There are *2* settings: one to specify specific plug-ins and one to specify
directories that contain plug-ins. I thought this would be obvious from
reading the config file which says:
'PlugIns': [],
'PlugInDirs': ['%(WebwarePath)s'],
Or even the docs!
http://webware.sourceforge.net/Webware/WebKit/Docs/UsersGuide.html#Config_AppServer
:-)
Spot on!,
-Chuck
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
