On Wed, Jan 28, 2009 at 01:15:41PM +1100, Ben Finney wrote:
Trent Nelson writes:
On Wed, Jan 28, 2009 at 08:18:51AM +1100, Ben Finney wrote:
Jesse Noller writes:
I think adding the windows services functionality distracts from the reasonable goal of the PEP Ben is proposing.
Thanks, this is my position also.
I disagree. Partly because I'm in a bit of a devil's advocate mood at the moment. But mostly because I know what will happen: [???]
I respectfully suggest that this isn't true, because your hypothetical situation continues:
After poking around the source, I'm perplexed. It's not doing anything uniquely Unix-xy,
Your disagreement seems to rest on this assertion, and I don't see how your hypothetical described can be true. Do you really see the described behaviour in the current draft PEP as ???not doing anything uniquely Unix-y????
No, the PEP is nothing but Unix-isms, that's my point. The 3rd party code I'm hypothetically wading through has been coded to that interface, but semantically, it's not doing anything unique to Unix.
`prevent_core` :Default: ``True``
If true, prevents the generation of core files, in order to avoid leaking sensitive information from daemons run as `root`.
I was going to suggest service.set_secure(True); but then I wondered what is this actually achieving? Won't the resulting .core will be owned by root?
`lockfile_directory` :Default: ``'/var/run'``
Absolute directory path to contain the daemon's lockfile. If ``None``, the lockfile behaviour for this daemon is skipped.
`lockfile_name` :Default: ``None``
Base name of the lockfile for this daemon, without directory or suffix. If ``None``, the name is derived from the process command line.
All you're doing is ensuring multiple instances of the daemon don't run. On Windows, you'd use a mutex, on Unix, sure, lockfile makes sense. A cross-platform interface wouldn't bother exposing this implementation detail.
just your normal, run-of-the-mill start/stop type stuff.
As far as I can tell, beyond trivial use cases, there is both wide discrepancy and very little overlap in ???start/stop type stuff??? between a Unix daemon and an MS Windows service. At least, none of the (admittedly few) instructions on MS Windows services I've seen demonstrate otherwise.
Semantically the overlap is almost identical, which is why I'm interested in hearing why the QtService-type approach couldn't be leveraged here. (The implementation details differ wildly, which is what you're referring to.)
Someone who thinks otherwise is welcome to attempt a PEP that brings all that behaviour under a single banner *and* design the API to be both flexible enough to be useful in many use cases and simple enough to be worth learning instead of doing it manually. That person will not be me.
class Service(object): EventType = namedtuple( Success = 1, Error = 2, Warning = 3, Information = 4, ) StartupType = namedtuple( Auto = 0, Manual = 1 ) def __init__(self, name, desc=None, startup_type=StartupType.Auto) self.name = name self.description = desc def parse_arguments(args): pass def is_running(self): pass def is_installed(self): pass def install(self): pass def uninstall(self): pass def report_event(self, msg, event_type, id, category, data): pass def exec(args): pass def terminate(): pass def request_pause(): pass def request_resume(): pass def send_command(code): pass def run(args): raise NotImplementedError() def start(): pass def stop(): pass def pause(): pass def resume(): pass }:> Trent.