[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Child killing UI (was Re: Reliability of RPC services)
From: |
Marcus Brinkmann |
Subject: |
Re: Child killing UI (was Re: Reliability of RPC services) |
Date: |
Fri, 28 Apr 2006 00:59:42 +0200 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Fri, 28 Apr 2006 00:34:57 +0200,
Pierre THIERRY <address@hidden> wrote:
> It would make the interface more complex, but the life of the user
> easier. Only the average computer-savvy knows how to kill a process from
> outside the application that spawned it, either in the shell or with
> some WM dialog.
>
> A menu that would have 'kill the X plugin', and/or maybe a watchdog that
> barks at the user when something goes wrong, would definitely help the
> user keeping its environment in a safe and working state with autonomy.
I don't see a problem with providing users a process tree and the
option attempt to kill parts of the tree, including leaf-nodes.
The only problem is if your jobs are not cooperating: If the browser
has been compromised and refuses to kill the plugin for example. In
that case, the only option you have is to go up in the process
hierarchy and kill parent jobs until you found one that is
cooperating. This search will stop at the shell.
As long as we make clear to the user that success is _only_ guaranteed
at the top level of the tree, there shouldn't be any problem.
A similar issue arises with authorising access to files via the
powerbox: A browser could advise the user that access to a file is for
a certain plugin only. But the browser can compromise this guarantee
and provide the same file to other plugins. Thus, the decision must
be a made by forming the intersection of access you are willing to
grant each component along the path.
Thanks,
Marcus
- Re: Reliability of RPC services, (continued)
- Re: Reliability of RPC services, Michal Suchanek, 2006/04/26
- Re: Reliability of RPC services, Pierre THIERRY, 2006/04/27
- Re: Reliability of RPC services, Michal Suchanek, 2006/04/27
- Re: Reliability of RPC services, Filip Brcic, 2006/04/27
- Process Management (was: Re: Reliability of RPC services), Marcus Brinkmann, 2006/04/27
- Re: Process Management (was: Re: Reliability of RPC services), Jonathan S. Shapiro, 2006/04/27
- Re: Process Management (was: Re: Reliability of RPC services), Marcus Brinkmann, 2006/04/27
- Escaping it's parents (was Re: Process Management (was: Re: Reliability of RPC services)), Pierre THIERRY, 2006/04/27
- Re: Escaping it's parents (was Re: Process Management (was: Re: Reliability of RPC services)), Marcus Brinkmann, 2006/04/27
- Child killing UI (was Re: Reliability of RPC services), Pierre THIERRY, 2006/04/27
- Re: Child killing UI (was Re: Reliability of RPC services),
Marcus Brinkmann <=
- Re: Child killing UI (was Re: Reliability of RPC services), Pierre THIERRY, 2006/04/27
- Re: Child killing UI (was Re: Reliability of RPC services), Marcus Brinkmann, 2006/04/27
- Re: Child killing UI (was Re: Reliability of RPC services), Pierre THIERRY, 2006/04/28
- Re: Child killing UI (was Re: Reliability of RPC services), Bas Wijnen, 2006/04/28
- Re: Child killing UI (was Re: Reliability of RPC services), Marcus Brinkmann, 2006/04/28
- Re: Child killing UI (was Re: Reliability of RPC services), Bas Wijnen, 2006/04/28
- Re: Child killing UI (was Re: Reliability of RPC services), Pierre THIERRY, 2006/04/28
- Re: Child killing UI (was Re: Reliability of RPC services), Jonathan S. Shapiro, 2006/04/28
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25