site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=r9euJFfOCodPDWOH7pJkL+y+Eqnl+g/IlUf7k+GZg5ThuSh9tCy5CP5IMPiVaipA91FOuCsv6Vd1Y+AJM341nq0+tGdqC3BtJYYlYiD1PMOWBek/JdB7X+49jG6/g8pbNBgUZIC2t7KtadbKNVmfy+XeTtloFha1UEbCtsu8Vtk= At 10:45 AM +0100 5/15/06, Finlay Dobbie wrote:

On 15/05/06, Kevin Van Vechten <kevin@opendarwin.org> wrote:

...

Lastly, StartupItems are on their way out, and unless you're seeking compatibility with pre-Tiger (10.4) systems, you'd be better off using a launchd plist.

launchd doesn't have daemon dependency support, last I checked.

That's because the dependency mechanism is much tighter than strings. launchd allows daemons to "publish" a service via an IPC mechanism such as a socket or mach port. Clients connect to the known port, and bing! the service appears. That's all well and good if you're in control of all the variables in the equation and don't mind special-casing OS X support. That's much more efficient than starting a service and vending a name hoping someone wants to use it, or wants to wait for it. Depends. In a server environment, I'd want the service available and ready to take client connections immediately - without any startup overhead - especially if it needs to perform lengthy initialisation. -- Finlay _______________________________________________ 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... On 15/05/06, Peter Bierman <bierman@apple.com> wrote: This email sent to site_archiver@lists.apple.com