>I'm not sure we are disagreeing, caching is definately the responsibility
>of the client or the server, which is precisely why I call it a "hint",
>typically the concept of hint is where something tries to give a clue as to
>how to handle it, in other words its something that a smart client can
>exploit. Typically in caching schemes (and I think I built the biggest one
>on the net - AOL's 18Gbyte Gopher cache!) the problem is what to cache and
>for how long, a "hint" explicitly does NOT say use the cache to find the
>object, it says to the client that having fetched the object it would
>sensible to KEEP a copy in the cache because the server (or the object)
>knows that the client is probably going to want it again soon. This should
>ONLY effect the speed, absolutely no change in what gets displayed to the
>user.
While I have a better understand of how "hint" would operate, I still
disagree about it belonging in the object specification. My first question
would be, why does the client or server *need* a hint? Say the client
application keeps a log of how often it has recieved a request for a
particular object. To the client, an object is an object regardless of
whether it is a descrete (.wrl) or contained within a (.wrl). If it notices
that it has grabbed the same object 3 times in the last 5 days, it may
decide to keep a local copy of it. (ie: the client is a "smart" replicator).
Next time the object is fetched, the client only needs to load it from local
storage. That is smart replication on the client side. I suppose you can
guess how smart replication on the server side would work. With both of
these working together, you can have very efficient access to objects. This
would be totally separate from the idea of defaults and need not clutter the
object description language with more keywords. In this way the ODL stays
just that, a description of the objects and does not try to help or
orchestrate the components that serve and receive it. And, as with your
desire, nothing about the physical appearance of the object is changed, just
the effieciency with which it is accessed.
>I guess I'm saying that the URL is (in the abscence of URNs) the name of
>the object. Much better than arbritray names like "teapot" because they
>also say how to get the generic object if I dont have it cached, or on my
>CDROM etc.
Okay, I see this as separate from the cache stuff but... In what way better
than an arbitrary name? An abstract dynamic name can be a powerfull thing
when it comes to using objects. The client or server can have a dictionary
of hashed keys that have many URLs (or something similar with URNs) for a
given object name. In the same way, it can have a single name for many URLs,
it could also have many names for a single URL. Since we are talking about
objects, I see no reason not to think about object memory and references.
References and pointers are powerfull tools that no programmer would be
without. I'm not reccomending that it be added, but I do think aliasing is a
great thing to have.
>
>I agree, and look forward to suggestions!
>
I'll send you any additional ones I have. Currently, all I can think of is
object naming (or aliasing, if you prefer), keeping anything about accessing
the object out of the ODL and having objects be able to be either defined by
a (.wrl) or contained in a (.wrl) (ie: VRML is heirarchical).
>In your suggestion, I think the disagreement is not in generic, versus
>specific functionality, its in where the control goes, I believe that the
>world builder is the one who should control what gets seen, so as an object
>builder I put together a kitchen and say that I'd like this really cool
>teapot, but in its abscence I'm willing to put up with the generic teapot
>that is specified here, I'm typicalyl not going to want to allow just any
>old thing that someone else has called a teapot, and if I was a competent
>world-builder then I'd test my world with both the specific and generic
>components.
Well, I'm more disturbed about adding keywords into the ODL for the
retrieval of the object but I do have some differing opinions on your above
comment, so here they are. I'm much more excited about the possibilities of
user configurability than the ability for an author to keep his world in his
own image. Excuse the excessive use of "world", but the world just doesn't
work that way. If I design a world, for example, it might be hard for me to
let go of it and give it up to the public, but still I would be really
excited to see how people have decided to (for example) furnish my space.
What sort of things have they done to my space to make it more enjoyable for
them. Like I said, however, I'm not too passionate about named objects at
this point. But I do think they are important if you are going to want
people to really interact with a world, feel that it has become theirs or
even be able move things around. On one hand, if someone decorates a store
painstakingly to do some electronic commerce, they may not want someone
coming in and making their own version of it. On the other hand, if that's
what it takes to get someone to spend more time their, they'll probably want
them do it.
Robert