From: Tavis R. <ta...@ca...> - 2001-11-01 21:57:11
|
THE PROBLEM ------------------------------------------------------------------------------------------------------- Webware's package layout / component system needs refactoring for the following reasons: * it relies too heavily on a particular directory structure, which will cause problems with a system-wide install via distutils. * it will lead to namespace pollution of PYTHONPATH when the transition is made to system-wide installs. * it dictates too much about how components/plugins should be packaged and documented. * some of the kits should really be part of WebKit's core. For example, COMKit functionality can easily be coded directly into the AppServer (or MultiPortServer in the redesign code I've been working on). It took 8 lines in the redesign code, rather than 93 lines in 2 extra files and 4 directories with COMKit. Ditto for TaskKit. The code for managing SessionStores in the redesign code was more compact, more efficient and much simpler without TaskKit. * my old objection to the name WebKit: for marketing and ease of introduction reasons it is better to position Webware as "A Python-Powered Application Server, that comes with a object-oriented library of useful components" than as "a suite of software components for developing object-oriented, web-based applications." WebKit is the heart of Webware, so why not get rid of the extra name to explain? Also see my proposed package structure below for more reasons. Its sounds like Webware will eventually be packaged using distutils. At that time all the Webware components will be sitting in /usr/local/lib/Python-x.x/site-packages. Think of how MiscUtils, WebUtils, etc. will look there. Chuck has mentioned the use of a Webware.pth file to group all the Webware components into a 'Webware' sub-directory that gets added into PYTHONPATH; thus requiring no major change to the existing Webware directory structure. I'd argue that this is hack to avoid. Sure it's a quick solution, but it's really no different than putting all the Webware subdirs directly into site-packages. It solves none of the issues listed above. Instead of just having 'Webware' in the PYTHONPATH namespace we'll have: [internally developed components] - WebKit - MiscUtils - WebUtils - UserKit - COMKit - TaskKit - MiddleKit - PSP [externally developed components] + Cheetah + FunFormKit + etc. THE SOLUTION ------------------------------------------------------------------------------------------------------- 1) Refactor the directory/package layout: Make all the components that are developed in the main Webware CVS subpackages of the main 'Webware' package: [internally developed components] - Webware (with all the WebKit classes at the top-level) Webware.MiscUtils Webware.WebUtils Webware.PSP Webware.UserKit Webware.MiddleKit [externally developed components] + Cheetah + FunFormKit 2) Refactor the component/plugin loading system: It currently operates through the file system. It is better to have the plugins loaded as live Python classes and leave where they come from upto the launcher script, or whatever is loading the system. This is much more flexible and suited for growth! 3) Merge COMKit into the core as I've done in the redesign code I've been working on. 4) Get rid of TaskKit. It's better to do this sort of stuff on a case-by-case basis, as illustrated by the implementation of SessionStore in the redesign code. Simpler, faster, smaller. ADVANTAGES ------------------------------------------------------------------------------------------------------- * no namespace pollution: only 1 name is exposed in PYTHONPATH rather than 8! * simpler to explain and document * more flexible as it uses Python's package system rather than relying on a particular directory layout. * easier to customize Webware for new uses * no mangling of PYTHONPATH or sys.path is required. QUESTIONS & ANSWERS ------------------------------------------------------------------------------------------------------- Q: But won't this break existing code? A: No! I've written some code to make sure that import statements that rely on the existing structure will continue to work. Q: Where would the docs and examples go for the components? A: For the internally developed components they would go either in the main Users' Guide (my pref), or in the package dir of each component. NB: I've written some distutils code that allows the docs to be installed centrally in site-packages as 'data-files'. For externally developed components, such as Cheetah, they would go wherever the components' developers want to put them. Note, I'm also advocating that the Webware docs be written in LaTeX, like Python's and Cheetah's, so they can be output in multiple formats. Rather than having separate docs for each component, I'd suggest having a Beginners' Guide, an Users' Guide, and a Developers' Guide. Each internally developed component would have a chapter in the relevant Guides. Q: But won't it take too much effort to change? A: No, most of the work is already done. Besides a little effort now will pay off big-time in the future as Webware grows. It's better to do this sort of refactoring while Webware is still young. |
From: Chuck E. <Chu...@ya...> - 2001-11-01 23:06:54
|
At 02:06 PM 11/1/2001 -0800, Tavis Rudd wrote: >THE PROBLEM >------------------------------------------------------------------------------------------------------- >Webware's package layout / component system needs refactoring for >the following reasons: > > * it relies too heavily on a particular directory structure, which > will cause problems with a system-wide install via distutils. The only real problem I'm aware of here is the mixture of directories that get written to (Cache/ Sessions/ etc) into the code directory. I think MakeAppWorkDir addresses some or all of that, but clearly some clean up and/or better docs in this area would be nice. > * it will lead to namespace pollution of PYTHONPATH when the > transition is made to system-wide installs. I'm not aware that individuals will need to modify their PYTHONPATH environment variable. See more below. > * it dictates too much about how components/plugins should be > packaged and documented. I disagree vehemently. The whole idea behind Webware components is that you would know the answers to all of these questions immediately: - where are the docs? - where are the examples? - where are the tests? - what are the properties (version, author, dependencies, etc.)? - will this package load on this platform? ...while still maintaining valid Python packages. e.g., even with all the conventions I have added on, you still just dump your *.py code in a directory with an __init__.py and then do this: from MiddleKit.Core.Attr import Attr > * some of the kits should really be part of WebKit's core. For > example, COMKit functionality can easily be coded directly into > the AppServer (or MultiPortServer in the redesign code I've > been working on). It took 8 lines in the redesign code, rather > than 93 lines in 2 extra files and 4 directories with COMKit. > Ditto for TaskKit. The code for managing SessionStores in the > redesign code was more compact, more efficient and much simpler > without TaskKit. I don't have a strong opinion on COMKit either way. Maybe Geoff, who wrote it, does. I strongly disagree about rolling TaskKit into WebKit. How would someone use TaskKit independently of WebKit, if it were rolled into WebKit? I think the answer is that they couldn't. Ditto for MiddleKit and UserKit. Also, I'm not aware of anyone having difficulties using Webware due to TaskKit being a separate package. I will not allow WebKit to become a monolith. It's an extensible app server. Things like task scheduling and object-relational-mapping will be separate packages that focus on having their own docs, tests, examples, independent usability, and WebKit integration. > * my old objection to the name WebKit: for marketing and ease of > introduction reasons it is better to position Webware as > "A Python-Powered Application Server, that comes with a > object-oriented library of useful components" than as > "a suite of software components for developing object-oriented, > web-based applications." WebKit is the heart of Webware, so > why not get rid of the extra name to explain? Also see my > proposed package structure below for more reasons. The name WebKit does not prevent our marketing Webware in a certain way. The name is final. For an example of the discontinuity between marketing and reality, see Microsoft. :-) >Its sounds like Webware will eventually be packaged using distutils. >At that time all the Webware components will be sitting in >/usr/local/lib/Python-x.x/site-packages. Think of how MiscUtils, >WebUtils, etc. will look there. Chuck has mentioned the use of a >Webware.pth file to group all the Webware components into a 'Webware' >sub-directory that gets added into PYTHONPATH; thus requiring no >major change to the existing Webware directory structure. I'd argue >that this is hack to avoid. Sure it's a quick solution, but it's >really no different than putting all the Webware subdirs directly >into site-packages. It solves none of the issues listed above. I thought the *.pth was a feature of Python, not a bug. Other than your personal distaste for it, I don't see any compelling reasons why it must be avoided. >Instead of just having 'Webware' in the PYTHONPATH namespace we'll >have: >[internally developed components] >- WebKit >- MiscUtils >- WebUtils >- UserKit >- COMKit >- TaskKit >- MiddleKit >- PSP >[externally developed components] >+ Cheetah >+ FunFormKit >+ etc. I agree that after a site wide install, you should be able to do this: from MiscUtils import NoDefault and NOT this: from Webware.MiscUtils import NoDefault My plan is still to accomplish this with Webware.pth. Having the Webware packages sit next to each other *is key*. It allows programs like WebKit's Launch.py and MiddleKit's Generate.py to ensure that the MiscUtils and other packages they use come from their own Webware package and not from some other location. For your average user, they don't care, but also won't be bothered or burdened. For developers like me who may have more than one Webware on a box, this is essential. >THE SOLUTION >------------------------------------------------------------------------------------------------------- >1) Refactor the directory/package layout: >Make all the components that are developed in the main Webware CVS >subpackages of the main 'Webware' package: > >[internally developed components] >- Webware (with all the WebKit classes at the top-level) WebKit will NOT be put at the top level. The name will NOT be removed. I'm final on that. > Webware.MiscUtils > Webware.WebUtils > Webware.PSP > Webware.UserKit > Webware.MiddleKit The names like "MiddleKit" will be accessible without "Webware", as in: from UserKit import UserManager This allows: * easy assimiliation of SomeKit into Webware that was previously external * easy break out of SomeKit into a separate project, if that is ever desired >[externally developed components] >+ Cheetah >+ FunFormKit > >2) Refactor the component/plugin loading system: >It currently operates through the file system. It is better to have >the plugins loaded as live Python classes and leave where they come >from upto the launcher script, or whatever is loading the system. >This is much more flexible and suited for growth! We already have this today. The settings in AppServer provide _you_ the ability to dictate where plug-ins come from. Regarding them being classes, plug-ins are Python packages. Nothing wrong with that at all. Python packages are...well...Pythonic! >3) Merge COMKit into the core as I've done in the redesign code I've >been working on. I'll let Geoff comment on that. >4) Get rid of TaskKit. It's better to do this sort of stuff on a >case-by-case basis, as illustrated by the implementation of >SessionStore in the redesign code. Simpler, faster, smaller. Sometime a case-by-case basis can be convenient, especially for the quick crank. However, the Python package with docs, examples, tests, etc. tends to promote maturity and group focus. But if you want to start a thread on the virtues of using TaskKit vs. doing-it-yourself, feel free. I didn't write TaskKit, haven't use it yet and didn't integrate it into WebKit so I don't have much to say. However, the folks who did seemed to discover some non-trivial issues and come up with a design they really liked. I think that's mostly Jay and Tom. I think people at Geoff's company have used TaskKit. >ADVANTAGES >------------------------------------------------------------------------------------------------------- > * no namespace pollution: only 1 name is exposed in PYTHONPATH > rather than 8! I don't think names like "MiddleKit" and "UserKit" are pollution. Again, this enables us to take out or put in new packages into Webware without any pain. And who wants to type the extra long "from Webware.MiddleKit.Core.Attr import Attr"? Not me. BTW I thought it was a pain when "DateTime" became "mx.DateTime", for example. > * simpler to explain and document Well, now that depends on who you are. ;-) When people have had trouble using UserKit and MiddleKit it has never been due to them sitting next door to WebKit instead of underneath it. > * more flexible as it uses Python's package system rather than > relying on a particular directory layout. Webware components *are* Python packages. If you don't believe me, start an interactive prompt and import one! But Python packages don't specify a standard for things like willLoad(), so Webware _adds_ to the package. This does not burden Webware users. > * easier to customize Webware for new uses Only with regards to putting more focus on having Webware write it's sessions, logs, etc. to a different location. Or at least an umbrella directory like "WebKit/var/" but with a better name. > * no mangling of PYTHONPATH or sys.path is required. That's just not a big deal. If everyone had to modify their environment, I would feel the pain. But the sitewide install should handle this transparently. >QUESTIONS & ANSWERS >------------------------------------------------------------------------------------------------------- > Q: But won't this break existing code? > A: No! I've written some code to make sure that import statements > that rely on the existing structure will continue to work. > > Q: Where would the docs and examples go for the components? > A: For the internally developed components they would go either in > the main Users' Guide (my pref), or in the package dir of each > component. NB: I've written some distutils code that allows > the docs to be installed centrally in site-packages as > 'data-files'. > > For externally developed components, such as Cheetah, they > would go wherever the components' developers want to put them. > > Note, I'm also advocating that the Webware docs be written in > LaTeX, like Python's and Cheetah's, so they can be output in > multiple formats. Rather than having separate docs for each > component, I'd suggest having a Beginners' Guide, an Users' > Guide, and a Developers' Guide. Each internally developed > component would have a chapter in the relevant Guides. Again you are debunking the notion that these components can be used independently. If you're concerned that people don't have easy access to all Quick Starts and all User Guide's, then we can write an index page that puts that together. > Q: But won't it take too much effort to change? > A: No, most of the work is already done. Besides a little effort > now will pay off big-time in the future as Webware grows. It's > better to do this sort of refactoring while Webware is still > young. We've discussed most of the above before. Of course, everyone is free to discuss as much as they want, but at some point an official decision should be made so we know where things will stand. As the project manager for Webware, here are some final decisions: These status quo items all stay: - the name Webware - the name WebKit - WebKit as an app server focused on easy of use and extensibility - Webware as an umbrella for Webware components - a Webware component is simply a Python package with some additional conventions - a WebKit plug-in is simply a Webware component loaded at launch time - if a WebKit plug-in needs to so some special set up, it does so via __init__.py like any good Python package does - It's "from SomeKit import SomeModule" and will not be "from Webware.SomeKit import SomModule" I agree that: - Webware should have a setup.py - Webware should make site-wide installation easy - Webware should make virtual hosting easy - Webware can always use better marketing including some good ideas from Tavis - WebKit should be more amenable and encouraging to writing all output to an umbrella directory that can easily live outside of WebKit/ - Webware needs a "Building a site" tutorial that takes the user through the steps of building a site, starting with WebKit and incorporating MiddleKit and UserKit. Basically, showing the canonical way to do things. I think that: - Webware programs like Generate.py and Launch.py need to use their own Webware components (I know this from experience). The Webware/ umbrella directory facilitates this. - Users who develop sites are not feeling burdened by anything other than: - lack of easy site wide install - lack of virtual hosting - the usual need for more docs, features and regression tests - Rearranging the directory structure wrt to WebKit vs. Webware and modularity, will not improve a Webware user's productivity. I'm open to: - more discussion on COMKit being external vs. internal to WebKit - more discussion as to the virtues of TaskKit ^ I suggest these become discussion threads in their own right. - focused, preferably-separate contribs like: - setup.py - WebKit's output directory is one, configurable umbrella directory You already have: - the ability to dictate what plug-ins are loaded or not loaded via WebKit/Configs/AppServer.config - the ability to develop kick ass sites with Webware (vorbis.com, foreclosures.lycos.com) :-) -Chuck |
From: Geoff T. <gta...@na...> - 2001-11-01 23:29:32
|
At 03:06 PM 11/1/01 -0800, Chuck Esterbrook wrote: >At 02:06 PM 11/1/2001 -0800, Tavis Rudd wrote: >> * some of the kits should really be part of WebKit's core. For >> example, COMKit functionality can easily be coded directly into >> the AppServer (or MultiPortServer in the redesign code I've >> been working on). It took 8 lines in the redesign code, rather >> than 93 lines in 2 extra files and 4 directories with COMKit. >> Ditto for TaskKit. The code for managing SessionStores in the >> redesign code was more compact, more efficient and much simpler >> without TaskKit. > >I don't have a strong opinion on COMKit either way. Maybe Geoff, who wrote >it, does. Because COMKit is so simple, it might be better to roll it into the core. Also, COMKit is useless outside of WebKit, so there's no strong argument for keeping it separate. >I strongly disagree about rolling TaskKit into WebKit. How would someone >use TaskKit independently of WebKit, if it were rolled into WebKit? I >think the answer is that they couldn't. Ditto for MiddleKit and UserKit. We use TaskKit in non-WebKit applications. It's useful in its own right. Let's keep it separate. -- - Geoff Talvola gtalvola@NameConnector.com |
From: Ian B. <ia...@co...> - 2001-11-01 23:30:52
|
Chuck Esterbrook <Chu...@ya...> wrote: > > * no namespace pollution: only 1 name is exposed in PYTHONPATH > > rather than 8! > > I don't think names like "MiddleKit" and "UserKit" are pollution. Again, > this enables us to take out or put in new packages into Webware without any > pain. And who wants to type the extra long "from > Webware.MiddleKit.Core.Attr import Attr"? Not me. > > BTW I thought it was a pain when "DateTime" became "mx.DateTime", > for example. What, no from net.sourceforge.webware.MiscUtils import NoDefault ?? :) |
From: Chuck E. <Chu...@ya...> - 2001-11-01 23:39:06
|
At 05:33 PM 11/1/2001 -0600, Ian Bicking wrote: >Chuck Esterbrook <Chu...@ya...> wrote: > > > * no namespace pollution: only 1 name is exposed in PYTHONPATH > > > rather than 8! > > > > I don't think names like "MiddleKit" and "UserKit" are pollution. Again, > > this enables us to take out or put in new packages into Webware without > any > > pain. And who wants to type the extra long "from > > Webware.MiddleKit.Core.Attr import Attr"? Not me. > > > > BTW I thought it was a pain when "DateTime" became "mx.DateTime", > > for example. > >What, no > >from net.sourceforge.webware.MiscUtils import NoDefault Sorry, you have to use Java to get features like that. :-) -Chuck |
From: Tavis R. <ta...@ca...> - 2001-11-01 23:45:02
|
Hi, I'm tempted to comment on some of the comments you've interspersed with my text, but I'll focus on your summary (thanks for summing it up, BTW): On Thursday 01 November 2001 15:06, Chuck Esterbrook wrote: > As the project manager for Webware, here are some final decisions: > > These status quo items all stay: > - the name WebKit > - WebKit as an app server focused on easy of use and > extensibility - Webware as an umbrella for Webware components I'll agree to disagree :-) ... what do other people think?? (I'm really curious) > - a Webware component is simply a Python package with some > additional conventions sure, but we shouldn't stipulate that the docs must be written in the same form as Webware's (HTML). I'm thinking from the perspective of Cheetah's docs here. > - a WebKit plug-in is simply a Webware component loaded at > launch time - if a WebKit plug-in needs to so some special set up, > it does so via __init__.py like any good Python package does But the loading logic should be handled by the launcher script rather than the AppServer itself. This is what I was getting at. > - It's "from SomeKit import SomeModule" and will not be "from > Webware.SomeKit import SomModule" 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. > I agree that: > > - Webware should have a setup.py > - Webware should make site-wide installation easy > - Webware should make virtual hosting easy > - Webware can always use better marketing including some good ideas > from Tavis - WebKit should be more amenable and encouraging to > writing all output to an umbrella directory that can easily live > outside of WebKit/ - Webware needs a "Building a site" tutorial > that takes the user through the steps of building a site, starting > with WebKit and incorporating MiddleKit and UserKit. Basically, > showing the canonical way to do things. Good! What do you think about using LaTeX? > I think that: > > - Webware programs like Generate.py and Launch.py need to use their > own Webware components (I know this from experience). The Webware/ > umbrella directory facilitates this. I can see your argument there, but how are externally developed packages such as Cheetah to fit in with this model? > - Users who develop sites are not feeling burdened by anything > other than: - lack of easy site wide install > - lack of virtual hosting > - the usual need for more docs, features and regression tests > - Rearranging the directory structure wrt to WebKit vs. Webware and > modularity, will not improve a Webware user's productivity. I'm thinking from the perspective of a component developer here. > I'm open to: > > - more discussion on COMKit being external vs. internal to WebKit Good. > - more discussion as to the virtues of TaskKit > ^ I suggest these become discussion threads in their own right. 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. > - focused, preferably-separate contribs like: > - setup.py > - WebKit's output directory is one, configurable umbrella > directory > 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 ability to develop kick ass sites with Webware (vorbis.com, > foreclosures.lycos.com) :-) This WEP is definately not disputing that. Webware rocks! Cheers, Tavis |
From: <ir...@ms...> - 2001-11-02 00:09:03
|
On Thu, Nov 01, 2001 at 03:54:24PM -0800, Tavis Rudd wrote: > On Thursday 01 November 2001 15:06, Chuck Esterbrook wrote: > > As the project manager for Webware, here are some final decisions: > > > > These status quo items all stay: > > - the name WebKit > > - WebKit as an app server focused on easy of use and > > extensibility - Webware as an umbrella for Webware components > > I'll agree to disagree :-) ... what do other people think?? (I'm > really curious) If you and I can agree to disagree about Cheetah, you and Chuck can agree to disagree about Webware. :) :) > > - It's "from SomeKit import SomeModule" and will not be "from > > Webware.SomeKit import SomModule" > > 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. Perhaps MiscUtils and WebUtils should be renamed then. Can they be made into proper Kits, so they can be *Kit like the others? Or put together in a package called WebwareMisc? > Good! What do you think about using LaTeX? It works, and it makes multiple output formats, but it's kind of kludgey for that, especially since it uses an anachronistic syntax (pre-XML). TeX's strengths are (1) mathematical formulas and (2) sophistocated typesetting. (1) doesn't apply because we aren't using complex mathematical formulas. (2) doesn't apply because nobody has a DVI-capable printer. Instead, people convert them to Postscript, using Postscript fonts instead of TeX fonts, and throwing away all the beautiful typesetting and kerning information TeX so painfully constructed, because the information is specific to the size and relative proportion of TeX font characters. If only XML had been available when TeX was designed, then we could have a universal rich text format that would work for both. Are there any SGML/XML-based formats (e.g., DocBook) that would be suitable without being overly complicated? -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@ji...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Tavis R. <ta...@ca...> - 2001-11-02 00:22:34
|
On Thursday 01 November 2001 16:13, Mike Orr wrote: > On Thu, Nov 01, 2001 at 03:54:24PM -0800, Tavis Rudd wrote: > > On Thursday 01 November 2001 15:06, Chuck Esterbrook wrote: > > I'll agree to disagree :-) ... what do other people think?? (I'm > > really curious) > > If you and I can agree to disagree about Cheetah, you and Chuck can > agree to disagree about Webware. :) :) [meaning the 'WebKit' name] of course, but vigorous debate is also good up to a point. If Ian had accepted my initial BDFL pronouncement about the parser architecture in Cheetah a lot of good things would have been missed. Of course, this issue is completely different. It's a subjective feeling about a name rather than an architectural issue. > > Good! What do you think about using LaTeX? > > It works, and it makes multiple output formats, but it's kind of > kludgey for that, especially since it uses an anachronistic syntax > (pre-XML). TeX's strengths are (1) mathematical formulas and (2) > sophistocated typesetting. (1) doesn't apply because we aren't > using complex mathematical formulas. (2) doesn't apply because > nobody has a DVI-capable printer. Instead, people convert them to > Postscript, using Postscript fonts instead of TeX fonts, and > throwing away all the beautiful typesetting and kerning information > TeX so painfully constructed, because the information is specific > to the size and relative proportion of TeX font characters. > > If only XML had been available when TeX was designed, then we could > have a universal rich text format that would work for both. Spot on!! Its features are very powerful, but its syntax sucks! > Are there any SGML/XML-based formats (e.g., DocBook) that would be > suitable without being overly complicated? Not that I know of. At this stage it's much easier to stick with LaTeX. |
From: Chuck E. <Chu...@ya...> - 2001-11-02 00:24:34
|
At 04:13 PM 11/1/2001 -0800, Mike Orr wrote: >Are there any SGML/XML-based formats (e.g., DocBook) that would be >suitable without being overly complicated? Um, HTML with styles? :-) |
From: Geoff T. <gta...@na...> - 2001-11-02 00:27:24
|
At 04:13 PM 11/1/01 -0800, Mike Orr wrote: >On Thu, Nov 01, 2001 at 03:54:24PM -0800, Tavis Rudd wrote: > > Good! What do you think about using LaTeX? > >It works, and it makes multiple output formats, but it's kind of kludgey >for that, especially since it uses an anachronistic syntax (pre-XML). ><snip> >If only XML had been available when TeX was designed, then we could have >a universal rich text format that would work for both. > >Are there any SGML/XML-based formats (e.g., DocBook) that would be >suitable without being overly complicated? I'm personally not too keen on having to write XML documents. XML is nice for machines to talk to one another, but as a human I cringe at the thought of writing a document directly in XML. I'd rather author docs using something like Wiki syntax, or StructuredText. Is there anything that can go from a StructuredText-like input to multiple output forms like HTML, PDF, and perhaps even the HTML Help format that's so useful on Windows? -- - Geoff Talvola gtalvola@NameConnector.com |
From: Ian B. <ia...@co...> - 2001-11-02 00:26:51
|
Tavis Rudd <ta...@ca...> wrote: > > These status quo items all stay: > > - the name WebKit > > - WebKit as an app server focused on easy of use and > > extensibility - Webware as an umbrella for Webware components > > I'll agree to disagree :-) ... what do other people think?? (I'm > really curious) It's a little confusing, but I do see the point of it. Maybe the *Kit name makes it more confusing. But eh... whatever. > > - a Webware component is simply a Python package with some > > additional conventions > > sure, but we shouldn't stipulate that the docs must be written in the > same form as Webware's (HTML). I'm thinking from the perspective of > Cheetah's docs here. Is there any such requirement? They have to be rendered into HTML for viewing through Webware, but that's obvious, since you view it through a browser. A more complete description might describe other versions of the documentation, but there'd be nothing to do with them now. > > - It's "from SomeKit import SomeModule" and will not be "from > > Webware.SomeKit import SomModule" > > 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. MiscUtils and WebUtils are kind of messy, and it is kind of lame they are in the top namespace. But "from WebUtils.Funcs import htmlEncode" is already really wordy. They're messy packages, and that's kind of the point. OTOH, I don't really feel they need to be accessible as external packages -- if anything in them is worth using outside, then it should be factored out better. I also really dislike WebUtils because, in order to get into WebKit I have to hit W<tab>K<tab> instead of just W<tab>. But that's probably not the best reason. > > I'm open to: > > > > - more discussion on COMKit being external vs. internal to WebKit > Good. But COMKit seems not to have anything to do with all those people who don't use Windows. It's already written, so if it's longer than necessary it doesn't really matter. Ian |
From: Chuck E. <Chu...@ya...> - 2001-11-02 00:05:36
|
At 03:54 PM 11/1/2001 -0800, Tavis Rudd wrote: > > - a Webware component is simply a Python package with some > > additional conventions > >sure, but we shouldn't stipulate that the docs must be written in the >same form as Webware's (HTML). I'm thinking from the perspective of >Cheetah's docs here. I would like to stipulate that after a standard installation, a Webware component will have a Docs/index.html in the current style, which is actually generated from the Properties.py of the component. Whether the manual(s) are generated to or written in HTML, I don't really care. What I care is that we can bind all these docs together so they are exceptionally easy to surf. > > - a WebKit plug-in is simply a Webware component loaded at > > launch time - if a WebKit plug-in needs to so some special set up, > > it does so via __init__.py like any good Python package does > >But the loading logic should be handled by the launcher script rather >than the AppServer itself. This is what I was getting at. I didn't know that was your view. You said something about how plug-ins needed to be classes (they are currently packages). 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. See more below. > > - It's "from SomeKit import SomeModule" and will not be "from > > Webware.SomeKit import SomModule" > >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? The Utils suffix is used for non-framework packages. Ideally, most or all of it would get pushed back into the Python distro, but I don't have time for the campaigning and even if we did that we would need a staging area anyway. > > I agree that: > > > > - Webware should have a setup.py > > - Webware should make site-wide installation easy > > - Webware should make virtual hosting easy > > - Webware can always use better marketing including some good ideas > > from Tavis - WebKit should be more amenable and encouraging to > > writing all output to an umbrella directory that can easily live > > outside of WebKit/ - Webware needs a "Building a site" tutorial > > that takes the user through the steps of building a site, starting > > with WebKit and incorporating MiddleKit and UserKit. Basically, > > showing the canonical way to do things. > >Good! What do you think about using LaTeX? I don't have a strong opinion on LaTeX yet and won't until I try it. I won't try it for a while because I've got bigger fish in my pan. Of course, if someone contributes a "Building a Webware Site" document, they can use whatever the hell they want! ;-) > > I think that: > > > > - Webware programs like Generate.py and Launch.py need to use their > > own Webware components (I know this from experience). The Webware/ > > umbrella directory facilitates this. > >I can see your argument there, but how are externally developed >packages such as Cheetah to fit in with this model? I would think Webware Deluxe would put Webware components under Webware/ and put non-components like MySQLdb in their typical place. > > - Users who develop sites are not feeling burdened by anything > > other than: - lack of easy site wide install > > - lack of virtual hosting > > - the usual need for more docs, features and regression tests > > > - Rearranging the directory structure wrt to WebKit vs. Webware and > > modularity, will not improve a Webware user's productivity. > >I'm thinking from the perspective of a component developer here. I suspected you might come back with that, but I already have my response: I don't see the burden for component author's either. Although the lack of docs about Webware components *is* a burden. > > - more discussion as to the virtues of TaskKit > > ^ I suggest these become discussion threads in their own right. >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? > > 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. > > - the ability to develop kick ass sites with Webware (vorbis.com, > > foreclosures.lycos.com) :-) >This WEP is definately not disputing that. Webware rocks! Thanks. -Chuck |
From: Tavis R. <ta...@ca...> - 2001-11-02 02:09:08
Attachments:
Launcher.py
|
On Thursday 01 November 2001 16:05, Chuck Esterbrook wrote: > At 03:54 PM 11/1/2001 -0800, Tavis Rudd wrote: > > > - a Webware component is simply a Python package with some > > > additional conventions > > > >sure, but we shouldn't stipulate that the docs must be written in > > the same form as Webware's (HTML). I'm thinking from the > > perspective of Cheetah's docs here. > > I would like to stipulate that after a standard installation, a > Webware component will have a Docs/index.html in the current style, > which is actually generated from the Properties.py of the > component. Thanks sounds sensible, but I still think the component should be required to provide the docs rather requiring Webware to know where to find the components docs. 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. > Whether the manual(s) are generated to or written in HTML, I don't > really care. What I care is that we can bind all these docs > together so they are exceptionally easy to surf. A valid goal! > > > - a WebKit plug-in is simply a Webware component loaded at > > > launch time - if a WebKit plug-in needs to so some special set > > > up, it does so via __init__.py like any good Python package > > > does > > > >But the loading logic should be handled by the launcher script > > rather than the AppServer itself. This is what I was getting at. > > I didn't know that was your view. You said something about how > plug-ins needed to be classes (they are currently packages). 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. * 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 * the launcher script should also handle the monitoring behaviour and launching a non-persistent version of the AppServer. See the attached module. > 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'? ;-) At the moment AppServer and Application are doing things that they shouldn't be responsible for. Here's how I see WebKit working: 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. --------------------------------------------------------------------------------------------------- Dispatcher -- listens to a set of ports and dispatches incoming connections to the appropriate services, such as the AppServer (aka MultiPortServer) AppServer -- turns the incoming stream into a rawRequest and dispatches the request to the appropriate Application Application(s) (Transaction, Request, Response, Session, SessionStore, Servlet, Cookie, etc.) -- handles the request I'll post this on the Wiki as well for more comments. > See more below. > > > > - It's "from SomeKit import SomeModule" and will not be > > > "from Webware.SomeKit import SomModule" > > > >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. > > > I think that: > > > > > > - Webware programs like Generate.py and Launch.py need to use > > > their own Webware components (I know this from experience). The > > > Webware/ umbrella directory facilitates this. > > > >I can see your argument there, but how are externally developed > >packages such as Cheetah to fit in with this model? > > I would think Webware Deluxe would put Webware components under > Webware/ and put non-components like MySQLdb in their typical > place. More thought is needed on this as the setup.py of some components, such as Cheetah, must be called. Just plopping them into a Webware/ dir won't cut it. > > > - more discussion as to the virtues of TaskKit > > > ^ I suggest these become discussion threads in their own right. > > > >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. > > > 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? Tavis |
From: Chuck E. <Chu...@ya...> - 2001-11-02 20:44:05
|
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 |
From: <ir...@ms...> - 2001-11-02 21:09:19
|
On Fri, Nov 02, 2001 at 12:43:56PM -0800, Chuck Esterbrook wrote: > >> What clearly identifies MiddleKit and UserKit as being part of > >> Webware any more than *Utils? The Webware project is (or will be) known as "the organization that provides *Kit", just like Egenix is "the company that provides mx.*" and Zope is "the project that uses Z*". We have de-facto ownership of *Kit because nobody previously claimed it, so it would be gauche for anybody else to release a "*Kit" module either (1) at all, or (2) not conforming to the Webware *Kit structuring conventions. > 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. *utils, however, is one of the first terms many Python projects and local admins would consider for their miscellaneous modules, just like *lib. So it's unfair for us to monopolize it. Nor should we expect the local sysadmin to immediately connote Webware when he encounters a module called MiscUtils or WebUtils. How about WWMiscUtils & WWWebUtils, or ChuckMiscUtils & ChuckWebUtils, or ceMiscUtils & ceWebUtils (using Chuck's initials)? Those names are much less generic, thus making others feel better about giving Chuck "ownership" of those prefixes. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@ji...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Chuck E. <Chu...@ya...> - 2001-11-02 21:19:11
|
At 01:13 PM 11/2/2001 -0800, Mike Orr wrote: >How about WWMiscUtils & WWWebUtils, or ChuckMiscUtils & ChuckWebUtils, >or ceMiscUtils & ceWebUtils (using Chuck's initials)? Those names are >much less generic, thus making others feel better about giving Chuck >"ownership" of those prefixes. There's no way we're injecting my name into software components. I _like_ having a team of developers, patch contributors, users, etc. and not all software in those packages comes from me. I also strive to make Webware manageable without me, for example, documenting my release procedures and the style guidelines. I would also consider future packages like DBUtils if there is enough material to warrant them. I still don't think *Utils is out there, especially with a cap U. I chose it, in part, because I really hadn't seen it, which is also why I avoided *lib, not to mention those are usually modules, not packages. -Chuck |
From: Tavis R. <ta...@ca...> - 2001-11-02 22:11:48
|
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 |
From: Tavis R. <ta...@ca...> - 2001-11-02 00:13:35
|
> My plan is still to accomplish this with Webware.pth. Having the > Webware packages sit next to each other *is key*. It allows > programs like WebKit's Launch.py and MiddleKit's Generate.py to > ensure that the MiscUtils and other packages they use come from > their own Webware package and not from some other location. A user copy of Webware in PYTHONPATH will automatically override the system-wide 'site-packages' library. What do Launch.py and Generate.py do that requires anything outside of the standard PYTHONPATH behaviour? Are you talking about situations where you have multiple 'instances' of Webware or multiple 'versions' of it? With system-wide distutils installs, multiple instances will all be using the same codebase for things like MiscUtils so there's no issue there. It shouldn't be a problem with multiple versions either. As for your point about an internally developed component becoming an externally developed one and vice versa, that makes sense. The issue then becomes how to make the names more webware-specific for things like MiscUtils, or even UserKit as you just pointed out. It's the ambiguity of the names I don't like. |
From: Aaron H. <aa...@me...> - 2001-11-02 15:56:13
|
> 4) Get rid of TaskKit. It's better to do this sort of stuff on a > case-by-case basis, as illustrated by the implementation of > SessionStore in the redesign code. Simpler, faster, smaller. Can someone detail this for me? I'm running webware .6a1 and looking at the cvs online, but where is this new SessionStore? Thanks, -Aaron |