Re: Launch a user-process from daemon
Re: Launch a user-process from daemon
- Subject: Re: Launch a user-process from daemon
- From: "Rakesh Singhal" <email@hidden>
- Date: Thu, 15 Jan 2009 08:26:33 +0530
Hi Jason,
Thanks a lot. I have two applications, daemon application and GUI.
Constraints:
First constraint is daemon launches GUI whenever it requires. Daemon
checks for a particular USB device and then it launches the GUI. If at
boot time, device is already plugged-in then it will launch GUI in
starting only.
Second I can not make changes in GUI code, it will be launched by
daemon application.
If I use daemon as an agent then it is able to launch GUI, but I can
not use my daemon application as an agents cause I want two things:
1. Only one daemon for all logins.
2. I do not want system to close daemon application, when any user logs out.
Regards
rksinghal
On Wed, Jan 14, 2009 at 11:09 PM, Jason Coco <email@hidden> wrote:
>
> On Jan 14, 2009, at 12:22 , Rakesh Singhal wrote:
>
>> I have to read it completely but I would like to let you know that if
>> I use LaunchAgents then my GUI is getting launch through daemon
>> application. BUt I want to keep the daemon in LaunchDaemons and then I
>> want to launch my GUI using daemon.
>
>
> If this is what you want, you have to design it for this. Don't try and make
> your
> daemon launch a GUI. Instead, design two parts, the daemon and the GUI.
> Decide
> how you want them to communicate. You can use distributed objects in Cocoa,
> you
> could use a UD socket, you could use an IP socket... the choice is yours.
>
> Create the daemon and install it in /Library/LaunchDaemons. Have it listen
> using whatever mechanism you decide on (UD socket, DO, heck, mach port
> even),
> then install the GUI part in your user's LaunchAgents section. When the user
> logs on,
> the GUI will be launched by launchd and can then connect to the daemon and
> let it know that it just came up/get further instructions/whatever.
>
> That said, you should probably have a very good reason for doing this.
> Generally,
> when I create a daemon for some service and I want to have a GUI to interact
> with
> it, I /always/ let the user decide when to start and stop that GUI. For
> instance, I have
> written a daemon that controls a mail service. It comes up in the root
> namespace and
> is installed under /Library/LaunchDaemons/. It listens for management
> information
> on a UD socket. It uses the security framework to ensure that any user has
> been
> granted the system.privilege.admin right before it will respond at all.
>
> I then have a system panel plugin that does basic configuration. The system
> panel connects over the UD socket and provides information like whether the
> services is started/stopped... provides a button to recycle/stop/start the
> service
> and provides basic configuration information (start at launch, IP bindings,
> etc.).
>
> Finally there is a full GUI application. This GUI can do everything that the
> system
> panel can do, plus it will do real-time monitoring, allow performance tweaks
> and
> adjustments, and do a number of other things that don't make sense in the
> context
> of the system panel plugin. The GUI also communicates over the same UD
> socket.
>
> Using this design, I could easily create a text-only interface, a web
> interface, or any
> other number of interfaces. If I felt there was a need for remote
> configuration (right
> now there's a requirement /against/ that), I could add an IP socket as well
> (of course,
> this would then require some kind of distributed authorization to be added,
> but I digress).
>
> Basically, Rakesh, you have to look at your problem, look at the
> constraints, and look
> at the users and come up with a viable solution... then start coding. That
> is just
> as important as writing code. In this case, Mac users generally don't want
> all kinds
> of stupid GUI applications popping up when they start their computer. That
> is more
> of a Windows thing... and most Windows users I know hate this as well (they
> just
> accept it more readily because before NT 3.51 there really was no service
> mechanism
> for applications to use)... and of course, since NT 3.51 many programmers
> have been
> too lazy to write proper services so the design anti-pattern continues
> (although, to
> be fair, this is changing).
>
> If you have some background process that needs to run in the context of a
> user, however,
> from the time they log in, you could still use this approach. You write the
> daemon and
> use a UD socket for communication. You then write a background-only
> LaunchAgent
> that does whatever it needs to do and (for simplicity) maybe exposes a
> couple of DOs. Then
> the control panel and/or full GUI could interact with the LaunchAgent
> instead of with
> the daemon directly. This still lets you do any per-user background
> processing that
> you might want to do AND lets the user decide whether she wants to launch a
> GUI
> process.
>
> Anyway, I hope this helps you. Jason
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden