From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <8ccc8ba40705251336l1f00233w2caa597689428c05@mail.gmail.com> Date: Fri, 25 May 2007 22:36:33 +0200 From: "Francisco J Ballesteros" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] XML In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8ccc8ba40705251032i4bb955edwb81db136b44f948@mail.gmail.com> Topicbox-Message-UUID: 72e112fa-ead2-11e9-9d60-3106f5b1d025 We have something similar. When layout changes, an event is posted to /mnt/ports but that reports that a subtree changed. At that point, we must reread the subtree to detect changes. Knowing the dir hierarchy in advance can speed things up, and the toc file could be of help. But thanks for the idea. I'll give it a second thought. On 5/25/07, Steve Simon wrote: > > We're trying hard (by reading most of the tree concurrently, and using Op on the > > slow link) to get o/mero fast enough not to worry about TOC. But in > > any case, should we > > add toc, probably just a raw list of, say, one relative path per line, > > a-la-du, would suffice. > > I am not sure I understand your application, but > couldn't you implement it with a single virtual file that the window > manager creates, and which the remote client blocks on. When the > user changes the layout the info is written to the "changes" file. > > Thus the remote end can keep a cache of the window systems state > close to it by just reading a single file rather than scanning the > widget hierarchy. > > -Steve >