>Simple answer: It's not there any more. How can my browser load it if
>it's not there?
Okay, I didn't explain myself clearly. What I meant is that there is no
reason why any changes one makes (besides the author) should change what is
on the server and accessible to all. If I decide to put a new piece of
furniture in a world, it wouldn't necessarily change your view of that world
unless you as the author wanted peoples changes to have a global scope.
>You have spent a lot of time disagreeing, and acting confused about what
>I was trying to say.
I apologize, I wasn't trying to come off confused or like I was disagreeing
for the sake of disagreeing.
>If my "static" space depends on common or offsite
>cached objects, and the site that serves the object
>goes away, or deletes the object, my space will have
>to change. I don't want that.
I see, I thought we were debating the value of people being able to change
objects within a world from a creative point of view. The caching issue is
much different for me. In the scenario above I don't see it as being any
different an issue than what happens to an URL when the server serving the
HTML documents there either moves them or goes down. The result? A client
with a reference to that location can no longer find what he previously
found there. Am I understanding you more accurately now?
>This is an argument in favor of local caching: Some people
>need (artistic) control in order to produce their effect. Outside
>influences need to be limited or prevented.
This seems to be a slightly different issue to me and more like the one I
was discussing with you earlier. To me, this is resolved by you creating a
world that is an aggregation of static objects or objects that only have a
local scope. In other words, you have authored the world in a way that
explicitly demands to *not* be changed in any global or local way. The
mechanics of how it is served to a user shouldn't matter (i.e. Cached versus
non-cached, local or global) as long as it is presented in exactly the way
you authored it to be presented.
>On the other side of the problem, if I am willing to accept outside
>changes, like people wandering in and moving the furniture, then offsite
>caching is acceptable. If the remote site stops serving the object, or
>changes it, I'll have to accept the fact that my world will change as well.
I don't see why these two othogonal concepts need to be mixed. I know you
feel you have given the explaination of why they do, but I just don't agree.
I don't particularly think you are wrong, I just have a different opinion.
To me, these are the concepts we have discussed:
1. The ability for a client(s) to interact with and change some
aspects of a world.
2. Caching technology to save space or increase virtual bandwidth.
Sometimes it seems like there is a third concept:
3. A virtual library of VRML objects for use in authoring or viewing.
They both have equally important issues and concepts but I don't think they
need be interrelated.
>My personal opinion is that most people will want static objects, which
>implies local caching, or a dependable registry of standard objects. The
>dependable registry is the most desirable outcome, but is also the most
>expensive in terms of resources.
Well, with authors this is usually the case as they don't want anyone
changing what they have created. However, to create an exciting interactive
world where people can feel that they are a part of it (i.e. they all author
it together after its initial presentation) you will need both dynamic and
static objects as well, possibly as lexical scoping. If you do not want
this, then where's the rub? You can just use static objects.
>Yes, but being able to predict what is going to happen each time you use
>the program is a regular feature of all the software I ever used. What is
>being contemplted, here, is the equivalent of having your desktop
>arrangement open to being manipulated by the public. When you return to
>your machine, you have to hunt around for things, because they are not
>where you left them. Or, to continue the software metaphor, the contents
>of your File menu depends on which version of that menu the remote server
>happens to give you. If someone else changed it or deleted it, you lose
>control.
This is why I wanted it to be clear that I am proposing that "changes" or
"customizations" that a user apply to a world in an effort to make it their
own (or more the way they like) do not always affect what is on the server
(the world that is served to everyone). When I change a color on my desktop,
it does not affect your desktops configuration, just mine. However, there
are those cases where you would *want* it to affect the global world.
Examples of this would be networked interactions such as network Doom or
Descent or an IRC-like "bar" where when I move a bottle of McCallans 25 year
to my lips everyone sees me down it.
>The point, again: You want things changable, but you don't want them to
>change unless you are aware of it, or are willing to accept whatever
>happens. Local storage (caching), or strict registration are the only ways
>I can think of to enforce the control one wants when dealing with issues
>they wish to remain static. I feel that new users will be unhappy if they
>can't maintain some fixed points of reference from which to begin their
>exploration of cyberspace. Therefore, this idea of non-strict common
>objects will cause worlds to change often and without apparent reason, and
>will make cyberspace a difficult and confusing place to deal with.
A simple soloution would be to add some sort of lexical scoping to VRML objects.
>Remote-stored common objects, without some sort of registration, are a bad
>idea. People will wind up copying the objects, rather than give up control.
>This defeats half of the purpose of having common objects: cutting down
>on storage costs. The other half is having a place we can get cheap
>objects to build a quick space. This we can do with copying from a common
>server. No remote reference needed.
Agreed. However, if a client receives a world from a server and saves it to
his disk, there will never by a way to ever restrict him from altering the
world to his tastes and using it instead of the one on the server or from
scavenging the objects in it to create his own world. IMO, this is a good thing.
Robert