On Friday 02 November 2001 12:43, Chuck Esterbrook wrote:
> 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.
That's not likely. We could ask the developers to follow the /Doc
convention if it makes sense in their case. If someone is going to
provide docs they're not going to hide them! Anyway that wasn't my
point: """It would make more sense to me for a component to install
their docs to a central Webware location when its setup.py is run."""
We could facilitate this by providing a simple API for installing
stuff to the Webware Docs.
> 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?
I suppose you're right that it's not a huge ask, but some components
might be made up of sub-components, each with their own docs. Or as
in Cheetah's case, they might have a Users Guide, a Beginners' Guide
and a Developer's Guide. It's not a huge burden, but it's rather
rigid.
> >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.
Fair enough, but good factoring is important if a framework is to
grow gracefully. I used your argument two months ago when Ian
suggested an architectural change to Cheetah's parser. There were
things much higher up on my list of priorities, but the low-level
architectural change made it much easier to accomplish those higher
priority tasks.
It might be low priority to you, but I'm not asking YOU to code it.
I'm saying here's an idea, should we do it? If we agree to do it,
then I'll provide the code (which is basically already written).
> 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..."
This allows web site developers to:
- work with nicer config files. The current syntax isn't broken, but
it's not pretty. With this approach it is much easier to change the
layout/syntax of the config files, because they are all controlled
from one place.
- easily customize and extend the launch behaviour of WebKit
- work with a nicer command line tool for launching WebKit
This allows developers and patch writers:
- to understand the launch process more easily.
-
> > > 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.
See above.
> 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.
We've been through this before ... I'm not suggesting that we tie the
classes to any particular layout of config files. Quite the
opposite, that we should delegate the loading of config files to the
Launcher.
The Launcher could still load the settings for AppServer from
AppServer.config and the settings for Whatever from Whatever.config.
However, if we decide that it makes sense to have a single httpd.conf
style config file for WebKit the Launcher can handle that as well.
It would also be easy to allow both schemes.
This is going off on a tangent, but I still think it makes more sense
to use a single config file with sections. It's easy to explain,
document, and maintain. Have a look at the attached config file from
the redesign code. It's layout is far more flexible with the
multi-application framework than the current layout. The syntax is
also nicer.
> >------------------------------------------------------------------
> >---------------------------------
>
> Why do you put these huge lines of dashes in your e-mails? They
> always wrap and look strange.
To split things up, but obviously I'm making them too wide ... sorry
> 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
hmm, faulty memory ;)
Tavis
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
