I don't believe it has become a serious problem in the case of window manager
hints for X11 and other window system. Of course, an extension to the 3D
world could add excessive complexity.
justin@dsd.camb.inmet.com (Mark Waks) wrote:
>> For a possible alternative, consider one thought that I've been
>> playing with for some time (I proposed it here a long time ago) --
>> keyword-selected objects. In this scheme, you can provide keywords as
>> an alternative to the URL for an object; if the local system has an
>> object that fits those keywords, then it just uses that instead of
>> loading the URL across the Net. As a possible refinement, you can
>> define "mandatory" keywords (which a prospective object must match)
>> and "optional" keywords (which may be matched or not, at the discretion
>> of the browser).
I say -- excellent idea! I think this is a great example of extending
Al and Creon's suggestion for including logical specifications in
VRML. Mark's suggestion not only follows the spirit of Al and Creon's
but also directly addresses a problem unique to WWW, i.e., making links
themselves "logical links" so that a browser can either use the actual
link, a local substitute, a previously fetched and cached copy of the
original, or whatever else is appropriate. Also, his suggestion of
using "hints" or keywords in the VRML document to guide the browser as
to how much freedom it has to substitute for the actual link pointed at
by the anchor is very good, and I would say, in agreement with Al and
Creon's scheme.
By the way, this reminds me of a criticism I have of current versions
of Mosaic I've used. That is the limited control a user has over how
cacheing is done. I find that there are a number of home pages I visit
frequently that rarely change, some of which are rather time consuming
to transfer., esp. because of their inline images. I'd like to have
the option of asking Mosaic to permanently cache a file and its link
name and put the link name in a hashed list along with the timestamp of
when I cached it. Then the next time I try to access that link my
browser would first check my list of cached links, and if a hit is
found, first ask the server for a timestamp of the linked file on the
remote machine. If my copy is more recent than the remote one, use my
local copy, otherwise transfer the remote file. Maybe this already is
a feature of some HTML browser and I just don't know about browsers
that do this. But, I doubt it since this would require that HTML
anchor syntax include a field for providing the local link and
timestamp info with the timestamp on the remote link. And, I've never
seen that in any HTML specification document I've read. If anyone
knows about such a feature, please let me know.
It seems to me something like this would be a good idea for VRML. I'm
already frustrated by the long response times I sometimes experience on
todays's "Information Super-Highway", which according to the popular
press (who, of course, really know what they're talking about (:-)) has
about an order of magnitude fewer users today than it will in the next
3 to 5 years. Mark Waks' suggestion made me realize that the network
bandwidth problem will not only become more of a bottleneck in the
future, but that also some clever design ideas such as his would go a
long way towards alleviating the bandwidth problem. I'd propose that
VRML provide a feature to help a browser reduce unnecessary,
repetitious fetching of previously accessed remote files. Marks'
suggestion goes even further by allowing a browser to even eliminate
any remote fetching at all. Both of these suggestions could have a
significant impact upon WWW performance to compensate for hardware
limitations. To paraphrase our President's campaign motto, "It's the
software, stupid".
Lew Hitchner
Virtual Reality and Visual Simulation Consultant
Mountain View, CA
Voice: 415-964-9425
FAX: 800-825-7689 (USA)
FAX: 510-472-6951 (international)
email: hitchner@netcom.com
URL: ftp://ftp.netcom.com/pub/hi/hitchner/hitchner.html