[Python-ideas] Draft PEP: Standard daemon process library
ben+python at benfinney.id.au
Fri Jan 30 04:30:17 CET 2009
"Stephen J. Turnbull" <stephen at xemacs.org> writes:
> Ben Finney writes:
> > Those people would be well served by a putative "service" interface.
> > I would welcome such a PEP from you, since you seem to have fairly
> > solid ideas of what it should look like.
> AFAICS it looks like yours
I can't see how anyone could compare the latest version of this PEP
with the suggestions being made by Trent for an API, and conclude that
they are similar.
This might because the PEP isn't communicating very well. Does the
section “A daemon is not a service” help to explain the fundamental
difference between the model suggested by Trent, versus the model in
If not, is it made clearer by the addition of nearly a dozen extra
methods in Trent's suggestion, and several extra concepts, that are
extraneous to the task described in the PEP?
All of which seem ideally suited to a putative “service” API.
> I don't see on what grounds you object to exploring the possibility,
> since you say you don't know much about Windows services.
I have no objection to someone exploring a “service” interface.
Indeed, I applaud such efforts. But that's not what I'm addressing
with this PEP.
As for the possibility of using the daemon interface as the
Unix-specific implementation of the background-process *component* of
a service interface, I believe it would be very well suited for that.
But I am implementing the daemon API *now* because it's a distinct
task, that I've seen needed many times and implemented poorly in many
places. I would be delighted if someone who knows what they want from
a “service” interface could build that, entirely different, API
using a daemon as part of the implementation.
> Note that nobody is suggesting that you write the code that
> implements daemons via Windows services (of course they'd love it if
> you did!), only that you open up the API design to changes that
> would make some programs work on all platforms without conditioning
> on platform, and make all programs work with minimal
> platform-specific code.
I maintain that it would be better to specify a platform-agnostic
“service” API, that uses the “daemon” API as the Unix-specific
implementation of the background-process component of the service.
Meanwhile, I and others have a need for a simple, standardised,
one-obvious-way “daemonise the current program” library, *entirely
distinct from* any of ther extra baggage that comes with a “spawn a
separate process that I can then communicate with through channels”
API. I intend to satisfy that with this PEP.
\ “People demand freedom of speech to make up for the freedom of |
`\ thought which they avoid.” —Soren Aabye Kierkegaard (1813-1855) |
More information about the Python-ideas