j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On Tue, Jan 27, 2009 at 8:29 PM, Trent Nelson
On Wed, Jan 28, 2009 at 08:18:51AM +1100, Ben Finney wrote:
Jesse Noller firstname.lastname@example.org 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 have documented this now, and it will appear in the next version of the PEP.
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: the PEP gets approved, the daemon module gets written, and, because it's so useful, uptake is immediate, people start writing code that uses it.
Or is it? Don't get me wrong, I heart Unix. But I get paid to develop in Windows. Because frankly, that's where the big bucks are and it's an extremely satisfying transition to jettison all emotional reasoning and just work for whoever is willing to pay you the most. I highly recommend it. But for now, I digress.
Don't worry; I think most of us would gladly work for money. In fact, I would hazard most of us like money a lot.
So, back to your Unix-only daemon module. It's good. Great, in fact. All sorts of projects start using it. Subversion uses it to write some funky persistent daemon that speeds up hooks by 8000% percent. Well that's just super! I'd like to use that for one of my clients, but, argh, no, wait, I can't, it's trying to use some daemon module that Google tells me is Unix-only.
After poking around the source, I'm perplexed. It's not doing anything uniquely Unix-xy, just your normal, run-of-the-mill start/stop type stuff. Why on earth, I think to myself, is this great 3rd party Python utility using a Unix-only daemon module, thus requiring me to hack it to bits in order for it to run on Windows, wasting my time and my client's time.
Windows Services != Unix daemons. Admittedly, I haven't had to do it in awhile, but from what I remember, windows services are nowhere near the same type of beast as a unix daemon, and trying to make a unified daemon library that glosses over the differences might cause seizures and habitual smoking.
A unix-only daemon - and then a complimenting windows-only service library - makes sense. Ideally, they would have close to the same API, but I don't think log jamming all of the vagaries of both into one beast makes sense. Then again, my windows-ability is out of date and rusty.