[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Child killing UI (was Re: Reliability of RPC services)
From: |
Pierre THIERRY |
Subject: |
Child killing UI (was Re: Reliability of RPC services) |
Date: |
Fri, 28 Apr 2006 00:34:57 +0200 |
User-agent: |
Mutt/1.5.11+cvs20060403 |
Scribit Michal Suchanek dies 27/04/2006 hora 15:24:
> > Why should it be a nothing or all case? First, I'm not so sure it
> > would break encapsulation that much to be able to kill the plugin
> > from outside. Or it breaks it, but it is desirable anyway.
> How do you do that? If the plugin is started by the browser the
> storage and cpu time is supplied by it. No other process needs to know
> that the plugin was started. If you do not know it is running you
> cannot killl it.
Yeah, but as I said, in some systems that encapsulation is obviously
broken. POSIX seems a fine example, where processes are globally
registered. When I ask a tree view of the processes, I can view what
processes have be spawn by my browser. And slay them without mercy.
> The plugin is started and exclusively used by the browser so there is
> no problem with providing an option to kill it from the browser.
> Except it might make the browser user interface more complex.
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.
Ergonomically,
Nowhere man
--
address@hidden
OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
- Re: Reliability of RPC services, (continued)
- 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 <=
- 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/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