Probably a suitable compromise would be come up with GUI based
utility that facilitates the creation of launchd based services. I
am not sure what sort of form it would take on, but sometimes the
best alternative is provide a suitable tool that facilitates the
use of the technology at hand.
Andre
On 22-May-06, at 18:00 , Michael Bartosh wrote:
On May 22, 2006, at 10:40 PM, Kevin Van Vechten wrote:
I'd be surprised if there is not a platform specific line of code
in your program. You can wrap your launchd support in #ifdef
__LAUNCHD__ or something equivalent. It's overstating the
problem to say that you can't have a unified code base. Adding
Launchd support is a relatively small amount of code, I know from
experience. I think your sysadmins (customers) will ultimately
be pleasantly surprised by this investment. Your server can be
automatically kept alive. This and other servers can be
uniformly launched, stopped, and queried via launchctl or
programmatically.
That's fine. But what about the poor, dumb sysadmin who -can't
write code-. These guys are not developers. Most sysadmins aren't.
They take code developed by other people and deploy it themselves.
And they need consistent ordering and dependencies that they can
impose on that code.
You (Kevin) seem to acknowledge this when someone brings it up.
But the messaging from Apple seems to be 'use launchd, it's the
wave of the future!'
not
'You might want to use launchd eventually, it has some cool
features, but will create headaches for you in the short run'.
When the latter is far more accurate.
You're right. Launchd is cool. It does some very cool things. 90%
of the time those things are not accessible without dependency
checking various systems require.
I mean, at least add something to launchd.plist that can talk to
configd.. wait for specific configd states, like configd's kicker
does. That alone would make launchd -a lot- more useful.
-mb
