On 4/25/06, Jonathan S. Shapiro <[EMAIL PROTECTED]> wrote: > On Tue, 2006-04-25 at 00:46 +0200, Bas Wijnen wrote: > > So forget about all others for the moment, please. > > I am not interested in considering move-only capabilities. We looked at > them several times over many years and decided that (a) they create more > problems than they solve, (b) they don't actually solve any of the > problems that people *think* they solve, and (c) they have negative > performance consequences. >
ad (c) most features that add functionality require cpu cycles to implement it ad (b) Imagine a few scenarios: I get a plugin for my browser/image editor/whatever. My browser gives a the plugin a read capability to the content it is supposed to handle, and access to part of its window on the screen. If the plugin does not produce what I want I can a) kill the plugin from the browser b) kill the browser including the plugin Because of encapsulation I should not be able to kill the plugin separately from outside, and I do not need anyway. The browser either knows it has killed the plugin or is killed as well. No problem. I get a crappy USB web camera along with a crappy driver. I load the driver, connect the camera, and receive a few video frames. The driver now locks up (or at least stops sending more frames). I have no idea how the driver framework will look like but I expect two types of connections: a) connection between the camera driver and the USB bus driver b) applications waiting for video frames Since I remove the driver the driver within the driver framework (a) should be handled. It is probably the job of the driver framework to provide notifications and/or encapsulation for applications that want to handle (b). Given that there are input devices, mass storage, audio cards, graphics cards, and other stuff this may get quite interesting. I am a user with a disk formatted with a horrible filesystem like NTFS. I receive a shiny new filesystem translator that is supposed to allow accessing the disk. So I connect the disk to my machine, and attempt to mount it using the translator. Now I would like to try and open a file on the disk using OpenOffice. If it was already ported it would probably call some dialog provided by my shell. If that cannot get response from the translator in reasonable time I can just cancel the dialog and OpenOffice will get a response that no file was opened. But if OpenOffice uses a posix layer it just tries to open the file. It should still be possible to cancel the operation in OpenOffice but it will probably stay in progress inside the posix layer indefinitely. Introducing any proxies or layers for whatever reason introduces such problems. And I do not think that timeouts or watchdogs solve this on non-realtime system. Thanks Michal
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
