Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!microsoft!t-jondu From: t-jondu@microsoft.UUCP (Jonathan Dubman) Newsgroups: comp.sys.next Subject: Re: Browser auto-update Message-ID: <7361@microsoft.UUCP> Date: 14 Aug 89 22:32:46 GMT References: <7324@microsoft.UUCP> <800018@mrcnext.cso.uiuc.edu>Reply-To: t-jondu@microsoft.UUCP (Jonathan Dubman) Organization: Microsoft Corp., Redmond WA Lines: 39 In article J Greely writes: >Should I mention that any attempt to add this to the system would >result in my deep-sixing it faster than you can say "Design >Philosophy"? > > I am not fundamentally opposed to having the Browser update itself >when I select it, as long as it doesn't prevent me from logging out >when it hangs on an NFS file system, but anything more is, IMHO, >crossing the line. Absolute accuracy would involve deep ugly hacking, >and would give the kernel knowledge about the one true window system >(assuming it doesn't (*brrrr*) already). Nasty, unfriendly thing to >do. > I understand your position... I anticipated an answer like this. As the person who started this discussion, my philosophy, from the user's standpoint, is that it would be ideal to have the Browser always display the current status of the file system. If doing so screws something else up, then ok, forget it, but I think there's a compromise in there somewhere. I agree that the kernel should have no knowledge of the Browser. But it should allow for dynamic "extensions"- I should be able to insert a "wedge" in a kernel object that sends me a message whenever it does such-and-such. Now I'm not a kernel hacker, but I imagine there's some set of low-level functions that create, modify, and delete all files. (A basis for the operator space, if you will.) Do these functions overlap with pipes and sockets and so forth? If so, then I see we have an efficency problem if we insert a wedge at that level, and it should go somewhere else. Is the NeXT object-oriented enough to handle this or is this just a PIPE DREAM? :-) >-=- >J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely) Jonathan Dubman