Path: utzoo!attcan!uunet!husc6!bloom-beacon!HPFCLP.SDE.HP.COM!diamant From: diamant@HPFCLP.SDE.HP.COM (John Diamant) Newsgroups: comp.windows.x Subject: Re: changing menu widget behavior Message-ID: <8807050445.AA19625@hpfcjrd.sde.hp.com> Date: 5 Jul 88 04:45:29 GMT References: <8807041615.AA07061@devnull.sun.com> Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 36 > > That means even if > > it has the memory and will honor all uses of it, you still have to manange > > your own duplicate copy. That's a waste of time and resources (though you > > still get the benefit of the server's ability to be more efficient in > > handling it when it can). > That's also the way to make sure that your application will work across a > wide range of server implementations. No, it's worse than that. If servers were required to tell you whether they would provide backing store for a particular window, then applications could use that information wisely. The server would still be at liberty to refuse (for reasons of its own, including no backing store implemented) and the application would have to fall back to making its own. So, it would be just as portable as now. However, with the present situation, backing store doesn't prevent the application writer from duplicating the work already being done by the server, because he has no way of knowing whether the server will come through. That doubles the memory requirement for any use of backing store (one copy maintained by the server and one by the client), which severely limits its utility. > Making applications portable and > inter-operable is never free - but customers in general prefer the products > whose developers paid these costs. I never suggested anything that wasn't portable or inter-operable. Customers don't like software that is slow and a memory hog, which is the result of attempting to use backing store in the present protocol. All that it requires is that servers be up front and commit to how much (if any) backing store they will maintain. If the answer is none, that's fine. John Diamant Software Development Environments Hewlett Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {ihnp4!hpfcla,hplabs}!hpfclp!diamant