[Zope-dev] Is there an alternative to zdaemon?

[Jim Fulton]

Andreas Jung wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> - --On 22. Dezember 2006 15:55:48 -0500 Jim Fulton <jim at zope.com> wrote:
>> It has 2 major disadvantages:
>>
>> - It is ours. :)  We are bearing the burden of maintaining it.
>>    This is offset by the fact that it hasn't required much maintenance.
> 
> ..which is actually a sign of "it-just-works".
> 
>> - It is largely undocumented. This makes it much harder to use than it
>>    needs to be.  It also makes it under appreciated.  I made a start at
>>    fixing this yesterday:
>>
>>      http://svn.zope.org/zdaemon/trunk/src/zdaemon/README.txt?view=auto
>>
>>   It isn't very hard to use, so documenting it isn't really all that hard.
> 
> ...which is almost True for a lot of parts of the Zope 2 core  :-)
> 
> 
>> I wonder if we should be using some other daemon manager.  Arguably,
>> there's
>> no reason for the Zope project to maintain one if something is available
>> that does what we need.
> 
> I think (meanwhile) that this is not enough to justify the replacement of a 
> component. Replacing a Zope 2 component always caused some pain. So as a 
> rule for replacing something in the Zope 2 core we consider those rules:
> 
>  - the replacement solves  existing functional problems
> 
>  - it adds major functional benefits
> 
>  - no issues with backward compatibility, well tested etc.
> 
> For the Zope 2 core we must be very careful about changing stuff. Stability
> and backward compatibility are much, much more important for the end-user 
> than satisfying our replace-all-with-something-better drive :-)
> 
> Don't get me wrong but we've done some minor mistakes with replacing stuff 
> in the past  and because of that I became a bit conservative about changing 
> things. Of course I am only speaking for the Zope 2 core.

I feel the same need for conservatism.  These are all good arguments.

A strong counter force is that we seem to have more on our plate than we
can handle.  We either need to get more people helping, or we need to do
less.  Something to keep in mind is that many people who help now actually
want and deserver to be able to do new things too. :)

zdaemon is an interesting case because it is soooooooo non-zope and
(mostly) non-python specific.  I must say that it amazes me that there
isn't an established alternative out there.

One point in zdaemon's favor that I forgot about in my original analysis
is that it has a (also undocumented) subclassing API that allows applications
to add new commands.  We certainly leverage this to provide the debug and
run commands.

supervisor2 looks very cool.  But it is also "ours" in some sense.  It also
is much bigger than zdaemon.  It looks like like something that people will
often choose over zdaemon.  zdaemon is still attractive to me over supervisor2
because it is smaller, less ambitious and I already understand it. :) And, of course,
there are the good backward compatibility arguments that you make.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org