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