This is Browser-auto-update in view mode; [Up]
Date: Sun 11-Aug-1989 17:20:44 From: Unknown Subject: Re: Browser auto-update In article <7324@microsoft.UUCP> t-jondu@microsoft.UUCP (Jonathan Dubman) writes: >Is it possible to configure the Browser to automatically update whenever there >is a change in any of its directories? Manually updating is a pain. >Clearly this is not the ideal situation. The browser already does a reasonable job of discovering that what it is displaying is not conformant with filesystem reality. (How's that for a sentence?) I vote for a workspace default that tells the browser not to change its title, but rather to update itself when it notices that things have gone bump in the night. That way, we have the best of both worlds.
Date: Sun 12-Aug-1989 03:07:00 From: Unknown Subject: Re: Browser auto-update The catch is that **ANY** program could create/destroy files. I don't know if you have a machine with many users. The solution is 1. Have EVERY Unix program send an UPDATE message to the window server or browser. (Yeah, right!) 1a. Put such code into the open() and creat() library calls. OR 2. Change the kernal so that _it_ sends an UPDATE message to the window server EVERYTIME a file is created/destroyed. Clearly, any method to notify processes of filesystem changes is going to be messy and consume CPU cycles. I belive that Multifinder on the Mac sort of does this. Does anyone know the details? -------------------- Brad Carlson <carlson@mrcnext.cso.uiuc.edu> or <brad-carlson@uiuc.edu> University of Illinos--Micro Resource Center--NeXT guru >From: ali@polya.Stanford.EDU (Ali T. Ozer)
Date: Sun 14-Aug-1989 08:35:51 From: Unknown Subject: Re: Browser auto-update 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. -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely) >From: dschuetz@umd5.umd.edu (David Schuetz)
Date: Sun 14-Aug-1989 18:36:45 From: Unknown Subject: Re: Browser auto-update >In article <7324@microsoft.UUCP> t-jondu@microsoft.UUCP (Jonathan Dubman) writes: >Is it possible to configure the Browser to automatically update whenever there >is a change in any of its directories? Manually updating is a pain. Maybe everytime you click the mouse in the Browser panel, that is, every time you bring it to the foreground. I mean, if you're going to look at it, you ought at least to be so polite as to *tell* it that you're looking at it. But I agree, it should in return be so kind as to tell you what's really there, without being lazy and just telling you "well, these were here five minutes ago..." dschuetz@umd5.umd.edu >From: t-jondu@microsoft.UUCP (Jonathan Dubman)
Date: Sun 14-Aug-1989 22:32:46 From: Unknown Subject: Re: Browser auto-update <JGREELY.89Aug14043551@oz.cis.ohio-state.edu> In article <JGREELY.89Aug14043551@oz.cis.ohio-state.edu> J Greely <jgreely@cis.ohio-state.edu> 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 >From: hunt@tramp.Colorado.EDU (Lee Cameron Hunt)
Date: Sun 15-Aug-1989 15:04:39 From: Unknown Subject: Re: Browser auto-update In article <800018@mrcnext.cso.uiuc.edu> carlson@mrcnext.cso.uiuc.edu writes: >... >1. Have EVERY Unix program send an UPDATE message to the window >... >2. Change the kernal so that _it_ sends an UPDATE message to >... >Clearly, any method to notify processes of filesystem changes >is going to be messy and consume CPU cycles. I belive that Multifinder >on the Mac sort of does this. Does anyone know the details? I really think this issue is much simpler than all this. First, let me make a guess: Both the NeXT browser and the Mac Finder notice when files have been created or destroyed by POLLING THE MODIFY TIME of the directories they display; every n seconds, they look at the modify time on any displayed directory. The Finder then displays (or removes) any file name or icon that has been created (or destroyed). The Browser just changes its title. I stick by my suggestion to add a default to the Browser that, if set by the user, would make the browser update its views when its normal polling behavior detects a change. CPU cost? To those of you who leave it turned off, enough cycles to check a flag once every n seconds, given that the Browser is already doing stat calls every n seconds anyway. To those of us who turn it on, however long it takes to update the Browser, when the Browser is running and notices a change in one of its displayed dire s. All this talk about patching the kernel or libraries is, as someone mentioned, over the line. I realize that there are changes to files that do not involve changing the modify times on directories, such as file size changes. The macintosh Finder ignores these, and I don't think that's a bad policy; after all, the important thing is that the darn files show up and can be manipulated.
Date: Sun 15-Aug-1989 15:07:43 From: Unknown Subject: Re: Browser auto-update In article <800018@mrcnext.cso.uiuc.edu> carlson@mrcnext.cso.uiuc.edu writes: >... >1. Have EVERY Unix program send an UPDATE message to the window >... >2. Change the kernal so that _it_ sends an UPDATE message to >... >Clearly, any method to notify processes of filesystem changes >is going to be messy and consume CPU cycles. I belive that Multifinder >on the Mac sort of does this. Does anyone know the details? All this talk about patching the kernel or libraries is, as someone mentioned, over the line. I really think this issue is much simpler than all this. First, let me make a guess: been created or destroyed by POLLING THE MODIFY TIME of the directories they display; every n seconds, they look at the modify time on any displayed directory. The Finder then displays (or removes) any file name or icon that has been created (or destroyed). The Browser just changes its title. I stick by my suggestion to add a default to the Browser that, if set by the user, would make the browser update its views when its normal polling behavior detects a change. CPU cost? To those of you who leave it turned off, enough cycles to check a flag once every n seconds, given that the Browser is already doing stat calls every n seconds anyway. To those of us who turn it on, however long it takes to update the Browser, when the Browser is running and notices a change in one of its displayed directories. I realize that there are changes to files that do not involve changing the modify times on directories, such as file size changes. The macintosh Finder ignores these, and I don't think that's a bad policy; after all, the important thing is that the darn files show up and can be manipulated.
Date: Sun 16-Aug-1989 07:46:18 From: Unknown Subject: Re: Browser auto-update I've seen systems where processes could receive "file created in directory" signals. If you implement a sufficiently general facility, no one will mistake it for a kludge. :-) -=EPS=- >From: epsilon@wet.UUCP (Eric P. Scott)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.