The more I've been seeing "hing CACHE" the more I'm wanting to comment on in
and it seems as though it originated with you.
>Another is caching, we want to make sure that we are able to use a local
>object if we have it cached, this can apply whether we have the copy on CD
>or just cached from the last time we accessed it, and is independant of
>whether we use URL's or URN's to access the object. Note that one neat
>feature of using HTTP and Caching, is that we can have a CDRom with a bunch
>of cached objects, and still be able to retrieve later versions by HTTP
>since it can check for whether the object has been changed since the date
>on the version cached.
This is absolutely true and I've been think about this for a couple of
years. It first came up when I was thinking about CDRom subscriptions to
pages where your most efficiently accessed information is on CD and your
most up to date remotely. Of course, the _most_ efficiently accessed objects
are in ram, as I said in another message. Anyway, my basic point is that I
have no problem with the concept of caching. Where I disagree is to *where*
functionality for caching should be enabled. To me, caching functionality is
the responsibility of clients or servers and not objects. Objects should be
dumb.
>The third is defaults, i.e. how to I display a generic teapot while I'm
>waiting for the specific teapot. This should be orthogonal, for example I
>might really want http://obscure.com/realcoolteapot.wrl, but would accept
>http://vrml.com/generic/teapot.wrl. I think its important that the default
>should also be a URL (or URN), just one more likely to be cached.
This is where I start to disagree. First, if the idea of defaults is going
to be introduced to the spec (and I'm not all that certain they should be),
it should be completely isolated from the concept of caching. Not that they
couldn't work together, but conceptually they should be isolated and
encapsulated. Second, the problem I have with defaults is that they are not
generic. Because they are not generic they will add to the specification
with providing general functionality. This becomes especially apparent when
using a "default" keyword. If you really want defaults, I would try to come
up with something that would give you the functionality of defaults without
restricting is utility to defaults. One example of this would be "named
objects". If a facility for named objects where added to the specification,
one could use it for defaults as well as many other things such as user
defined objects or caching without directly addressing those issues. I'm not
sure if I am being clear, so let me know if I'm not and I'll give it another
shot. When I'm designing a language or framework and there is a need for a
new feature, I always ask myself, "can I make this feature possible by
adding general functionality? Or do I have to add code to specifically add
this feature." Almost always, I can come up with a general soloution that
while it does not address the feature directly, adds functionality that
enables the feature.
>Here is a suggestion that might allow us to handle this reasonably,
>although I'm much more interested in successfully seperating out the three
>concepts, than in using any specific syntax for it.
>
>WWWInline {
> name "http://obscure.com/realcoolteapot.wrl"
> default "http://vrml.org/generic/fancyteapot.wrl"
> default "http://vrml.org/generic/teapot.wrl"
> hint CACHE
>}
>
In the above example, we have three keywords that could all be addressed by
one abstraction. Once again, the first idea that pops into my head is "named
objects". Perhaps this could be done by expanding the semantic of the DEF
keyword or "=" operator, maybe variables could be introduced, I don't really
know. But lets try looking at it from a different perspective. Say that you
have "RealCoolTeapot.wrl" and it, as an object, could be named, like so:
#VRML V1.0 ascii
DEF Teapot
.
.
.
# end of RealCoolTeapot.wrl
The idea here is that there is no difference between someone creating a
Teapot inside of a (.wrl) and a (.wrl) *being* a teapot. They are both
Teapot's and they are both VRML objects, one just happens to be a file.
Then in the (.wrl) that uses it, the inline would be usual.
WWWInline
{
name "http://obscure.com/RealCoolTeapot.wrl" USE Teapot
}
The client application could either pull a Teapot up from local mass storage
or volitile memory, or it could load the URL. All that would be defined by
the user of the client application. If the browser didn't support this level
of configurability, it would just load the URL as normal. Additionally, a
user could tell the client application that whenever it encounters a Teapot
that it should always use "MyTeapot.wrl". This isn't a great example of
syntax and by no means indicates what I think is a passable soloution.
However, it does exemplify what I think would be a more general soloution
that would with less keyword additions provide more functionality. If you
disagree with all this (and I don't see why you shouldn't <g>) my main point
is that I don't think defaults or anything having to do with a cache should
be the responsibility of the VRML author (or the VRML specification for that
matter) it should be the responsibility of the Client or Server application.
Anyway, as is clear, I haven't thought this out much but I figured I would
throw in my two cents (plus) about caching and defaults.
Robert