> >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.
That is how I feel as well. If I create a world, I'd just as soon see it
be the same each time I go there, unless I actively make a change to it.
I'd accept some simplification if I actively set "low resolution" mode,
and I'd also accept a poor substitute for my "realcoolteapot" if the
teapot server is down, but not without some sort of notice which I
actively acknowledge. 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. The gist is: I want control.
On the other hand, there are other folks who will want a phone on a
table, and don't care what it looks like, just so it's identifiable, and
doesn't cost much (in terms opf resources) to place there. I, myself, at
times, wouldn't care about certain objects, given that they are unimportant.
With the above two ideas stated, I think we can go forward with the
Common Object discussion. We know we need some sort of system which
allows the inclusion of outside objects.
> 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.
I would have a hard time giving up control of a space I've spent a lot of
time one. On the other hand, I'd like to provide semi-public-controlled
areas that can accept minor changes. It would be nice is someone can stop
by and leave a package, or a chair or something nice to look at. Rather
than load up my hard disk with whatever people have been leaving in my
foyer, I'd just as soon they left a URL (URN).
Here's another idea: An Object Delivery Service. "Furniture of the Day".
You designate certain objects as generic, and replace-able. Each day you
wake up, and stroll into your space, and find a new couch and coffee
table, with your familiar phone and teapot on it. This would be a great
way to deliver regular updates to software (disks), newspapers, email, and
other things. I could even train my electronic dog to go get the newspaper
from the end of my virtual sidewalk.
> 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.
Control vs. interaction. Authors need to enforce various levels of
control, which gives them the ability to extract value from what they
have produced. We also need public areas where we can rub elbows and
enjoy the sorts of creations that other people come up with. Without the
latter, the ideas for the former would be hard to come by.
---
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>