Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-13 Thread Dieter Maurer
Chris McDonough wrote at 2003-3-11 15:32 -0500:
 > On Tue, 2003-03-11 at 15:22, Guido van Rossum wrote:
 > > 
 > > That's why we're including the correct versions of ZODB and ZEO in
 > > Zope itself.  That's already the case in Zope 2.6.
 > 
 > Zope 2.6 doesn't yet include ZEO, at least I don't think it does. ;-)

When you make a CVS checkout of the 2.6 branch, it already contains
ZEO.


Dieter

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-12 Thread Jamie Heilman
Toby Dickenson wrote:
> There is no amount of reconfiguration that can improve this in Zope2. Zope3 
> promises to fix this, but with modular python components rather than modular 
> unix components. I would be interested in your thoughts on whether this makes 
> a difference.

I don't think modular component libraries are a replacement for
modular programs, or vice versa.  They both have their place, they
both can be good or bad depending on the implementation.  (How's that
for a wishy-washy say-nothing statement. )  I simply haven't looked
seriously at Zope3 yet, because my needs and Zope3's timeline don't
coincide.  So unfortunately any opinons I could offer on Zope3's
direction would be wholely uninformed.

-- 
Jamie Heilman   http://audible.transient.net/~jamie/
"We must be born with an intuition of mortality.  Before we know the words
 for it, before we know there are words, out we come bloodied and squalling
 with the knowledge that for all the compasses in the world, there's only
 one direction, and time is its only measure."  -Rosencrantz

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-12 Thread Toby Dickenson
On Tuesday 11 March 2003 10:48 pm, Jamie Heilman wrote:

> > You'd probably still want a single master config file for the whole
> > thing, and a tool to check the configuration is valid separate from
> > the process that uses the file to configure itself.
>
> Not I.  Large applications with a master config file are to be held
> with suspicion.  Their longevity inevitably suffers because they are
> difficult to adapt to new situations.

Im not sure the "big config file" approach is necessarily less adaptable than 
the "big /etc directory" approach. It is the details that make the difference 
- both approaches can be done well.

> Another way to ease configuration is to make things modular so its
> easier to visualize the flow of data.

There is no amount of reconfiguration that can improve this in Zope2. Zope3 
promises to fix this, but with modular python components rather than modular 
unix components. I would be interested in your thoughts on whether this makes 
a difference.

-- 
Toby Dickenson
http://www.geminidataloggers.com/people/tdickenson

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Jamie Heilman
Chris McDonough wrote:
> On Tue, 2003-03-11 at 17:48, Jamie Heilman wrote:
> > How about, "a lot of code/documentation was removed, and a lot of new
> > code/documentation was added."  Don't get hung up on the exact
> > numbers, my point was, a lot of work has gone into "simplifying" the
> > configuration process, but that the bigger picture isn't any clearer
> > for it.
> 
> Given the circumstance, what would you propose to do?

Merge and move on, I'm not asking anyone to throw out their work,
just to give thought to what I've said.

-- 
Jamie Heilman   http://audible.transient.net/~jamie/
"We must be born with an intuition of mortality.  Before we know the words
 for it, before we know there are words, out we come bloodied and squalling
 with the knowledge that for all the compasses in the world, there's only
 one direction, and time is its only measure."  -Rosencrantz

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Chris McDonough
On Tue, 2003-03-11 at 17:48, Jamie Heilman wrote:
> How about, "a lot of code/documentation was removed, and a lot of new
> code/documentation was added."  Don't get hung up on the exact
> numbers, my point was, a lot of work has gone into "simplifying" the
> configuration process, but that the bigger picture isn't any clearer
> for it.

Given the circumstance, what would you propose to do?

- C



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Jamie Heilman
Jeremy Hylton wrote:
> I don't know what work means in this context, but think the ZConfig
> project is thorough.  In my checkout there are 180k of document, 180k of
> unit tests, and 136k of code.  A measure of work that suggests that
> something with 0k of documentation and tests and 136k of code would be
> better makes no sense to me.

How about, "a lot of code/documentation was removed, and a lot of new
code/documentation was added."  Don't get hung up on the exact
numbers, my point was, a lot of work has gone into "simplifying" the
configuration process, but that the bigger picture isn't any clearer
for it.

> I don't see where the UNIX philosophy has anything useful to say about
> configuration, but maybe I'm just a closet unix hater <0.5 wink>.

Small programs that do one thing well, written to work together,
communicating via a universal interface, have the golden property of
being easily replaceable.  With this replaceability comes the ease of
configuration.

> I don't see that configuration gets any easier if you have multiple
> processes.  Even if Zope had N processes, there would still be the same
> amount of stuff to configure.

There is more than one way to ease configuration.  Reducing the
"amount of stuff" is one way, but sometimes, even after you've reduced
till you can't reduce any further, there's still a lot of "stuff."
Another way to ease configuration is to make things modular so its
easier to visualize the flow of data.  When the boundaries of
communication are clearly defined between modules it becomes easier to
understand what part each module plays, and how you can affect the
overall result by changing or re-organizing the individual modules.

> You'd probably still want a single master config file for the whole
> thing, and a tool to check the configuration is valid separate from
> the process that uses the file to configure itself.

Not I.  Large applications with a master config file are to be held
with suspicion.  Their longevity inevitably suffers because they are
difficult to adapt to new situations.

> As I watched everyone working on the ZConfig project, I was
> impressed with how many issues are involved in getting a decent
> configuration system.

Indeed.

> I don't think that break the server into multiple pieces would make
> it easier to configure, and I don't see what requirements could have
> been eliminated to make the project take less work.

Well, when you've got some cycles to burn, give it some more thought.
It may not be as obvious to you if you don't deal with it on a day to
day basis like sysadmins do, but I assure you UNIX owes much of its
longevity to the philosophies upon which it was built.  Adaptability is
a big deal.

-- 
Jamie Heilman   http://audible.transient.net/~jamie/
"We must be born with an intuition of mortality.  Before we know the words
 for it, before we know there are words, out we come bloodied and squalling
 with the knowledge that for all the compasses in the world, there's only
 one direction, and time is its only measure."  -Rosencrantz

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Paul Winkler
On Tue, Mar 11, 2003 at 04:25:09PM -0500, Guido van Rossum wrote:
> > > Oops, I stand corrected.  But Zope 2.7 does include ZEO!
> > 
> > Very good!  But in that case, shouldn't the new Zope 2.7 install and 
> > startup stuff support it?
> 
> Well, in a typical installation, you won't be running ZEO on the same
> machine as Zope, right?  ZEO has its own install and config stuff,
> which is very similar to that for Zope, but ZEO is not installed as
> part of the main Zope install.

i suppose it's not typical but we run zeo on all our systems including
the dev boxes, because

* we like to have the same environment everywhere for sanity's sake

* interactive debugging is very cool and has saved my butt more
  than once.

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's FAT BOY!
(random hero from isometric.spaceninja.com)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Guido van Rossum
> > Chris, have you looked at ZEO/mkzeoinst.py?  It uses a somewhat
> > simpler approach than the new Zope setup, but it creates a zeoctl
> > script and a zeo.conf configuration file.

> Cool!  I didn't know.
> 
> Do you think we should tell people that if they want to run a ZEO server
> to just run mkzeoinst from the software home resulting from Zope's "make
> install" and to edit zope.conf to use a ClientStorage?

That should work, yes, as long as mkzeoinst.py, zdctl.py, zdrun.py and
runzeo.py are all on $PATH at that point.

--Guido van Rossum (home page: http://www.python.org/~guido/)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Chris McDonough
Cool!  I didn't know.

Do you think we should tell people that if they want to run a ZEO server
to just run mkzeoinst from the software home resulting from Zope's "make
install" and to edit zope.conf to use a ClientStorage?

> Chris, have you looked at ZEO/mkzeoinst.py?  It uses a somewhat
> simpler approach than the new Zope setup, but it creates a zeoctl
> script and a zeo.conf configuration file.



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Guido van Rossum
> > Very good!  But in that case, shouldn't the new Zope 2.7 install and 
> > startup stuff support it?
> 
> It does.  It's just that the default setup is still to use a non-ZEOd
> FileStorage for your main database.  But you can change options in the
> config file to make it use a ZEO ClientStorage.  This is in lieu of of
> requiring you to edit custom_zodb.py as you needed to do in 2.6 and
> prior.
> 
> It's clear that the Zope source distro should support the use of
> ClientStorage "out of the box".  It's not however so clear that the Zope
> source distro should make it to set up a ZEO server (although it does
> happen to include the necessary files to run a ZEO server too, it
> doesn't include a 'zeoctl' or a zeo.conf, etc).

Chris, have you looked at ZEO/mkzeoinst.py?  It uses a somewhat
simpler approach than the new Zope setup, but it creates a zeoctl
script and a zeo.conf configuration file.

> That's not to say that it shouldn't be easy to set up a ZEO server, but
> that making it easy should probably the job of a package other than Zope
> proper.  The right thing to do would be to package up a ZEO server
> installer separate from Zope 2.7 with a similar kind of buildout,
> support files, and configuration file.  At least that's been my idea so
> far.

Not needed; it's all there (though far simpler in approach than the
Zope installer).

--Guido van Rossum (home page: http://www.python.org/~guido/)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Chris McDonough
On Tue, 2003-03-11 at 16:12, Dan L. Pierson wrote:
> Very good!  But in that case, shouldn't the new Zope 2.7 install and 
> startup stuff support it?

It does.  It's just that the default setup is still to use a non-ZEOd
FileStorage for your main database.  But you can change options in the
config file to make it use a ZEO ClientStorage.  This is in lieu of of
requiring you to edit custom_zodb.py as you needed to do in 2.6 and
prior.

It's clear that the Zope source distro should support the use of
ClientStorage "out of the box".  It's not however so clear that the Zope
source distro should make it to set up a ZEO server (although it does
happen to include the necessary files to run a ZEO server too, it
doesn't include a 'zeoctl' or a zeo.conf, etc).
 
That's not to say that it shouldn't be easy to set up a ZEO server, but
that making it easy should probably the job of a package other than Zope
proper.  The right thing to do would be to package up a ZEO server
installer separate from Zope 2.7 with a similar kind of buildout,
support files, and configuration file.  At least that's been my idea so
far.

- C



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Jamie Heilman
Steve Alexander wrote:
> > But lo, still you won't be able to do something as
> >mundane as limit the memory the FTP server is able to consume without
> >affecting the HTTP server.
> 
> You can do this with Zope. Just use ZEO and run one ZEO front-end for 
> HTTP and one for FTP.

Sure, but then you carry along all the baggage of 2 zserver instances.
Its a start, but there's still a ways to go.

-- 
Jamie Heilman   http://audible.transient.net/~jamie/
"I was in love once -- a Sinclair ZX-81.  People said, "No, Holly, she's 
 not for you." She was cheap, she was stupid and she wouldn't load 
 -- well, not for me, anyway."  -Holly

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Guido van Rossum
> > Oops, I stand corrected.  But Zope 2.7 does include ZEO!
> 
> Very good!  But in that case, shouldn't the new Zope 2.7 install and 
> startup stuff support it?

Well, in a typical installation, you won't be running ZEO on the same
machine as Zope, right?  ZEO has its own install and config stuff,
which is very similar to that for Zope, but ZEO is not installed as
part of the main Zope install.

--Guido van Rossum (home page: http://www.python.org/~guido/)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Dan L. Pierson
--On Tuesday, March 11, 2003 03:43:33 PM -0500 Guido van Rossum 
<[EMAIL PROTECTED]> wrote:

On Tue, 2003-03-11 at 15:22, Guido van Rossum wrote:
>
> That's why we're including the correct versions of ZODB and ZEO in
> Zope itself.  That's already the case in Zope 2.6.
Zope 2.6 doesn't yet include ZEO, at least I don't think it does. ;-)
Oops, I stand corrected.  But Zope 2.7 does include ZEO!
Very good!  But in that case, shouldn't the new Zope 2.7 install and 
startup stuff support it?

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Guido van Rossum
> On Tue, 2003-03-11 at 15:22, Guido van Rossum wrote:
> > 
> > That's why we're including the correct versions of ZODB and ZEO in
> > Zope itself.  That's already the case in Zope 2.6.
> 
> Zope 2.6 doesn't yet include ZEO, at least I don't think it does. ;-)

Oops, I stand corrected.  But Zope 2.7 does include ZEO!

--Guido van Rossum (home page: http://www.python.org/~guido/)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Chris McDonough
On Tue, 2003-03-11 at 15:22, Guido van Rossum wrote:
> 
> That's why we're including the correct versions of ZODB and ZEO in
> Zope itself.  That's already the case in Zope 2.6.

Zope 2.6 doesn't yet include ZEO, at least I don't think it does. ;-)

- C



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Jeremy Hylton
> I'm not dismissing it, and I think you need to go back and read what I
> wrote again very very carefully without reading anything into it.  I'm
> not trying to imply that using environment variables to configure the
> current codebase will reduce the code footprint.  Even if it did,
> because of the distributed nature of the technique, its damnedly hard
> to maintain in a project as large as Zope.  Also, I didn't say ZConfig
> was 374k of code, I said it was 374k of *work*.   I chose that word
> very carefully, and obviously thats going to err on the side of
> conservatism as certainly the work was not isolated to that single
> directory tree.

I don't know what work means in this context, but think the ZConfig
project is thorough.  In my checkout there are 180k of document, 180k of
unit tests, and 136k of code.  A measure of work that suggests that
something with 0k of documentation and tests and 136k of code would be
better makes no sense to me.

> The point I'm trying to make is that Zope has learned nothing from the
> UNIX philosophy.  Yes, you can extend the config schema.  You can grow

I don't see where the UNIX philosophy has anything useful to say about
configuration, but maybe I'm just a closet unix hater <0.5 wink>.

> new, better config files, of extraordinary magnitude.  The
> all-powerful server will grow from being all-powerful to being
> all-powerful + n.  It will be able to read mail.  Its heralds shall
> sit upon mountain high throwns hewn of the finest O'Reilly and New
> Riders scripture.  But lo, still you won't be able to do something as
> mundane as limit the memory the FTP server is able to consume without
> affecting the HTTP server.

> Fracture the server infrastructure into small, seperate processes.
> The configuration of the individual pieces becomes trivial.  The
> understanding of the overall data flow improves.  When there's nothing
> left to remove from code, you've won.  Some of the breaks have already
> been made, like the separation of the storage from its front-end.
> Thats good, we need more action along those lines.

I don't see that configuration gets any easier if you have multiple
processes.  Even if Zope had N processes, there would still be the same
amount of stuff to configure.  You'd probably still want a single master
config file for the whole thing, and a tool to check the configuration
is valid separate from the process that uses the file to configure
itself.

As I watched everyone working on the ZConfig project, I was impressed
with how many issues are involved in getting a decent configuration
system.  I don't think that break the server into multiple pieces would
make it easier to configure, and I don't see what requirements could
have been eliminated to make the project take less work.

Jeremy





___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Paul Winkler
On Tue, Mar 11, 2003 at 10:01:53AM -0500, Dan L. Pierson wrote:
> I don't see an equivalent to "./zctl.py debug" anywhere.  This starts up an 
> interactive Python as
> a ZEO client with ZServer and Zope imported and app = Zope.app().  I use it 
> constantly.  Please?

+1.  I also use zctl.py debug nearly every day.

of course it's just a convenience, but it's an important
convenience because nearly every document i can find
on debugging Zope says roughly "...and of course you
can use ZEO, but that's beyond the scope of this article..."

-- 

Paul Winkler
http://www.slinkp.com

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Steve Alexander
> But lo, still you won't be able to do something as
mundane as limit the memory the FTP server is able to consume without
affecting the HTTP server.
You can do this with Zope. Just use ZEO and run one ZEO front-end for 
HTTP and one for FTP.

--
Steve Alexander
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Guido van Rossum
> The point I'm trying to make is that Zope has learned nothing from the
> UNIX philosophy.  Yes, you can extend the config schema.  You can grow
> new, better config files, of extraordinary magnitude.  The
> all-powerful server will grow from being all-powerful to being
> all-powerful + n.  It will be able to read mail.  Its heralds shall
> sit upon mountain high throwns hewn of the finest O'Reilly and New
> Riders scripture.  But lo, still you won't be able to do something as
> mundane as limit the memory the FTP server is able to consume without
> affecting the HTTP server.
> 
> Fracture the server infrastructure into small, seperate processes.
> The configuration of the individual pieces becomes trivial.  The
> understanding of the overall data flow improves.  When there's nothing
> left to remove from code, you've won.  Some of the breaks have already
> been made, like the separation of the storage from its front-end.
> Thats good, we need more action along those lines.

You're barking up the wrong tree.  Zope 2 won't change.  Zope 3 is
still in a state of flux, and that's where you should aim your
speech.

--Guido van Rossum (home page: http://www.python.org/~guido/)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-10 Thread Paul Winkler
On Mon, Mar 10, 2003 at 10:31:13PM -0500, Fred L. Drake, Jr. wrote:
> Detaching, or "daemonizing", will be a separate configuration
> parameter from everything else.

great, that is exactly what i really want.

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's GARGANTUAN SKULL OF THE REVOLUTION!
(random hero from isometric.spaceninja.com)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-10 Thread Fred L. Drake, Jr.

Edward Muller writes:
 > Actually I like the way z2.py detaches or doesn't detach. Perhaps a
 > separate config option would be good to control this.

Detaching, or "daemonizing", will be a separate configuration
parameter from everything else.  The basic mechanism will be that
provided by the zdctl.py/zdrun.py scripts in the zdaemon package.


  -Fred

-- 
Fred L. Drake, Jr.  
PythonLabs at Zope Corporation

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-10 Thread Edward Muller
On Mon, 2003-03-10 at 17:07, Paul Winkler wrote:
> A few questions / concerns listed below, otherwise it looks
> fine to me...
> 
> On Mon, Mar 10, 2003 at 04:41:48PM -0500, Chris McDonough wrote:
> >   debug mode
> 
> does this still toggle a whole bunch of things?
> 
> >   production installation (on/off)
> 
> what's this mean?
> 
> >   network servers (http, dav, ftp, monitor, etc)
> 
> is this where you set the ports?
> 
> One thing I didn't see in your list is a way to extend the products
> path (currently I do that with $PRODUCTS_PATH).  We need that.
> 
> One more question: Does "zopectl.py" always detach from the terminal
> (booo) or not (yay) ?  
> Or does it behave like z2.py and this depends on "debug mode" (booo) ?

Actually I like the way z2.py detaches or doesn't detach. Perhaps a
separate config option would be good to control this.

-- 
Edward Muller

Interlix - President

Web Hosting - PC Service & Support
Custom Programming - Network Service & Support

Phone: 417-862-0573
 Cell: 417-844-2435
  Fax: 417-862-0572

http://www.interlix.com


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-10 Thread Chris McDonough
On Mon, 2003-03-10 at 21:42, Jamie Heilman wrote:
> Chris McDonough wrote:
> The point I'm trying to make is that Zope has learned nothing from the
> UNIX philosophy.  Yes, you can extend the config schema.  You can grow
> new, better config files, of extraordinary magnitude.  The
> all-powerful server will grow from being all-powerful to being
> all-powerful + n.  It will be able to read mail.  Its heralds shall
> sit upon mountain high throwns hewn of the finest O'Reilly and New
> Riders scripture.  But lo, still you won't be able to do something as
> mundane as limit the memory the FTP server is able to consume without
> affecting the HTTP server.

Point taken.

> Fracture the server infrastructure into small, seperate processes.
> The configuration of the individual pieces becomes trivial.  The
> understanding of the overall data flow improves.  When there's nothing
> left to remove from code, you've won.  Some of the breaks have already
> been made, like the separation of the storage from its front-end.
> Thats good, we need more action along those lines.

I think this is a noble goal, but far beyond the scope of the current
project, which is stated on the project page as "Make it easier for
sysadmins and new Zope developers to install and configure Zope".  I
believe that ZConfig will help us towards this goal.  It should also not
hinder us from reaching the goal that you've defined above.

Thanks,

- C




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-10 Thread Jamie Heilman
Chris McDonough wrote:
> 
> Before dismissing it out of hand, I'd encourage you to try it out.  

I'm not dismissing it, and I think you need to go back and read what I
wrote again very very carefully without reading anything into it.  I'm
not trying to imply that using environment variables to configure the
current codebase will reduce the code footprint.  Even if it did,
because of the distributed nature of the technique, its damnedly hard
to maintain in a project as large as Zope.  Also, I didn't say ZConfig
was 374k of code, I said it was 374k of *work*.   I chose that word
very carefully, and obviously thats going to err on the side of
conservatism as certainly the work was not isolated to that single
directory tree.

The point I'm trying to make is that Zope has learned nothing from the
UNIX philosophy.  Yes, you can extend the config schema.  You can grow
new, better config files, of extraordinary magnitude.  The
all-powerful server will grow from being all-powerful to being
all-powerful + n.  It will be able to read mail.  Its heralds shall
sit upon mountain high throwns hewn of the finest O'Reilly and New
Riders scripture.  But lo, still you won't be able to do something as
mundane as limit the memory the FTP server is able to consume without
affecting the HTTP server.

Fracture the server infrastructure into small, seperate processes.
The configuration of the individual pieces becomes trivial.  The
understanding of the overall data flow improves.  When there's nothing
left to remove from code, you've won.  Some of the breaks have already
been made, like the separation of the storage from its front-end.
Thats good, we need more action along those lines.

-- 
Jamie Heilman   http://audible.transient.net/~jamie/
"Paranoia is a disease unto itself, and may I add, the person standing
 next to you may not be who they appear to be, so take precaution."
-Sathington Willoughby

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-10 Thread Chris McDonough
On Mon, 2003-03-10 at 19:51, Jamie Heilman wrote:
> > - Environment variables are no longer used for configuration.
> 
> I'll say it one more time.
> 
> The roadmap[1] states under the "Simplifying the Zope experience"
> section:
> 
> * simple tasks should be simple!
> 
> Now, code required to extract a value from the environment:
> 
> import os
> try: value = sanitize(os.environ.get("SOMETHING", default))
> except Unsanitary:
>...cope...
> 
> # where 'sanitize' is in reference to any conversion procedures required
> # prior to the use of 'value' by program code

I'm sure you know this, but you are oversimplifying the situation. 
There are 41 (known) individual environment variables that control
Zope's runtime configuration.  Each use of an environment variable has
its own parsing code, its own error-handling code and the actual code
that does the work (ex: the session envvar parsing stuff in
OFS/Application.py).  If we take your example and make the error
handling code "real" and the work code "real" we can estimate that it
will consume about 1k. Multiply the number of bytes it contains with 41
and we can approximate about 41k of ad-hoc envvar handling code in Zope
now.  That's a boatload of largely untested and decentralized code, all
of which is doing configuration.  There is nothing simple about it. ;-)

> Pretty simple.  Enter ZConfig:
> $ du -sk ZConfig
> 374 ZConfig
> 
> 374k of work devoted to replacing os.environ.get and its sanitizing
> code, and the result is a XML config file.  I'm not saying this all
> for naught, but really, it should give you pause.  Just how much have
> you really simplified configuration by doing this?

I couldn't really guess how much code in Zope is devoted to runtime
configuration right now because it's spread over the entire codebase.  I
suspect you're right that it's not 374k.  But for ZConfig only 116k is
code, the rest is docs and tests: there are neither (to speak of,
discounting the laughable ENVIRONMENT.txt) in the current 2.6/trunk
codebase for configuration.

> Personally I think the problem of Zope's configuration hassles has
> been mis-identified.  ZConfig cleans up and centralizes a maze of
> badly strewn out configuration code.  It will extend the lifetime of
> the Über-server concept ZServer employs.  It does nothing to prevent
> the same mess from happening again, down the road.

Actually, it does.  Packages may declare their own config schema type
definitions and they may be included in the context of a larger
configuration schema.  This is demonstrated in the Zope schema in the
new-install-branch in lib/python/Zope/Startup/zopeschema.xml:



  

  
  
  



We import the schema type definitions from the zLOG, ZODB, and ZServer
packages here (these are named component.xml in each of these
packages).  The zope schema file uses these definitions to compose its
own (type-checked) schema for a config file, and they can be (and will
be) reused for ZEO and ZC's ZRS (Zope Replication Server).

For Zope, ZServer is just another package that happens to define the
schema type definitions for network servers.

>  I believe a more
> lasting approach is to seperate the servers into small individual
> programs which only do 1 thing, and do it well.  Then you combine
> those servers under a unified mangement framework, connect them
> together by using common communication idioms, the idea being--and
> follow me here, to use small programs combined together to provide a
> larger service.  Sound familiar?

I think this is done already.  ZConfig is very general and very generic;
you can configure just about anything with it and it has no Zope
dependencies whatsoever.  Fred Drake wrote it so it's pretty solid too.

Before dismissing it out of hand, I'd encourage you to try it out.  

- C



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )