site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com Hmm. This leaves us with two of launchd's goals in conflict; one is that apps shouldn't have to contain extra code to handle the way they're launched, the other is that they should robustly handle services which aren't up yet but may be later. I guess, insofar as launchd is requiring me to rewrite code that's working fine elsewhere, and add apple-specific startup magic, it's not a feature. It may be that this inconvenience is worth it for the other benefits, but to deny that it is an extra workload and an extra inconvenience is implausible. -pmb _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... At 3:05 AM -0500 5/22/06, Peter Seebach wrote: Dave Zarzycki writes: We only expect what our customers (including system administrators) expect: Robust, easy to use and flexible software. I also have no doubt that our customers want to see daemons be more resilient to the real world, which will, in the end require the use of IPC. No, the IPC mechanisms that launchd tunnels are generally ones that block on connection attempts. So clients can be completely unaware of launchd, or whether the service is always running or launched on demand. And servers only need to declare to launchd what their existing IPC mechanism is via a plist. If your "code" is an existing StartupItem that works, you don't need to change it. If your code is an existing IPC service, it's trivial to define that service in a launchd.plist. If your code is an IPC service that's currently wrapped in a StartupItem, consider moving to launchd so that your clients don't need to also use a StartupItem to declare their dependencies. That's the major advantage of launchd: clients just use the services they need, there's no additional declaration of dependency required. This email sent to site_archiver@lists.apple.com
participants (1)
-
Peter Bierman