It's not a bad idea, although I think that turning it into reality may
prove tricky -- you may well find that the growth of kinds of "hints"
quickly turns explosive when you try to apply it generally. (I'm not
sure of this; it's just a hunch.) I think I'd need to see some more
truly concrete examples...
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).
In the current scheme, I guess this would be a multiple-string
parameter to the WWWInline node, sort of like this:
...
WWWInline {
requiredKeywords {
"refrigerator"
}
optionalKeywords {
"large"
"top-freezer"
}
name "http://www.inmet.com/~justin/fridge.vrml"
}
...
So, seeing this, a clever browser might check whether we have a large,
top-freezer fridge locally; if not, it would go out to the Web for the
object. This would provide a way of "caching" objects, as well as
customizing the way that you see the Web a bit. There are some weaknesses
to the scheme, but it's basically pretty sound.
I still think it's an interesting idea, and may well push for it again
one of these days. In the first go-round, several people opined that
the URL working groups should be dealing with these local-cache issues;
I'm not sure I really believe that they'll get a good solution, but I'm
willing to give it some time. Besides, this is *definitely* a second (or
third) cut issue...
-- Justin
Random Quote du Jour:
"Neurosis is the inability to tolerate ambiguity."
-- Sigmund Freud, appearing to John Barlow in a dream