> >I also don't want to walk into my space and find
> >that one of the objects has disappeared, since the site at which it was
> >stored decided to delete the object.
>
> Why would that happen?!?
Simple answer: It's not there any more. How can my browser load it if
it's not there?
Rather than make a huge reply to everything you said, I decided to boil
it down to just this one thing.
You have spent a lot of time disagreeing, and acting confused about what
I was trying to say. I must have been unclear. The fact that you didn't
understand the quoted statement above shows why, I think. I was speaking
on both sides of the caching/common objects problem. 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. 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.
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.
The point is this: If we accept the idea of common objects not being
under any control (non-registered), then we depend on the graces of the
server operators not to change the objects out from under us. This will
work in some cases, but not in others.
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.
> For example, someone may be alone in
> a world but may want to lay it out to their liking. This is precisely why
> when people who want to exert control are in charge of building user
> interfaces, the result is user interfaces that people feel restricted by.
> While a UI needs a common metaphore, it also needs to be something that the
> user feels he can make his own. He needs to feel at home in that workspace.
> Visual people, in particular, have a hard time with giving up control, they
> believe their visual representation is the best and don't want others
> changing it, even if they don't have to see the changes one makes.
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.
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.
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.
---
Andrew C. Esh mailto:[email protected]
Computer Network Technology [email protected] (finger for PGP key)
6500 Wedgwood Road 612.550.8000 (main)
Maple Grove MN 55311 612.550.8229 (direct)
<A HREF="http://www.mtn.org/~andrewes">ACE Home Page</A>