Re: Launch, connect, communicate
Re: Launch, connect, communicate
- Subject: Re: Launch, connect, communicate
- From: Alastair Houghton <email@hidden>
- Date: Wed, 17 Aug 2016 19:06:38 +0100
On 16 Aug 2016, at 00:26, Andrew Keller <email@hidden> wrote:
>
> 1. If the main Plot app is _not_ running in the current Aqua session, then launch a new copy in the current Aqua session.
> 2. Open some sort of a socket to the main Plot app in the current Aqua session.
> 3. Accept numbers on stdin, and forward them through the socket to the main Plot app.
> 4. When stdin is exhausted, exit.
>
> This architecture would, I believe, pave the way for some really neat improvements in the future.
>
> So then, here comes the question. #1 and #2 above strike me as something that Launch Services and/or launchd might be capable of, but I’m having trouble identifying a set of APIs that would perform this task. I’ve found lots of documentation on having one master app delegate services to a helper that’s launched on-demand, but nothing yet on having _two main apps_ — one of them command-line and one of them Cocoa — where one can launch and subsequently communicate with the other, and then die.
#1 happens automatically and is done for you. You can just launch your application using e.g. NSWorkspace’ -launchApplication: method an edit will do the right thing. (You could use Launch Services directly if you want, via e.g. LSOpenCFURLRef(), though I’d prefer NSWorkspace if you can use Objective-C in your command line tool.)
#2 is a bit more complicated, because there can be multiple GUI sessions these days. Using raw sockets is making things hard for yourself; if I were you, I’d look at either (a) making your application scriptable (then you can send Apple Events containing the data you read from the command line, plus users will be able to use AppleScript to feed data to your application), or (b) using Distributed Objects (which is very easy and can do per-session endpoints very straightforwardly via NSMachBootstrapServer and NSMachPort).
It’s a shame it isn’t possible to use XPC for this (well, it *is*, but it requires using a deprecated API).
You could also use sockets, if you really wanted; the best way would be to put a UNIX socket in the user’s private temporary directory. This, of course, assumes that the same user can’ have multiple GUI sessions, which is a reasonable assumption I think, but one that the DO and scriptability approaches don’t need to make.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden