j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
"Stephen J. Turnbull" email@example.com 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 the PEP?
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) | _o__) | Ben Finney