Re: [ogpx] Definitions of terms to be used in my (our?) communication

[Carlo Wood <[e-mail]>]

On Mon, Aug 31, 2009 at 04:06:48PM -0700, Infinity Linden wrote:
> On Mon, Aug 31, 2009 at 3:29 PM, Carlo Wood<[e-mail]> wrote:
> > On Mon, Aug 31, 2009 at 11:08:13AM -0700, Meadhbh Siobhan wrote:
> >> but before i comment on these terms, let me point out that while this
> >> discussion is interesting and germane to the subject of virtual
> >> worlds, it is a bit out of scope for a discussion about the charter.
> >> so, can we just for right now, just use the terms that have been
> >> defined in the way that they're defined and get through the charter
> >> bashing?
> >>
> >> i PROMISE you, that we'll get back to terms in more detail, and
> >> honestly, i like your use of the term "universe."
> >
> > that feels to me ... like pushing it through.
> 
> and saying that we don't want to start _any_ work before we all agree
> on every term seems obstructionist to me.
> 
> >
> >> in the current OGP/VWRAP documents, the term "island" and "galaxy" aren't used.
> >
> > great then it won't give rise to confusion
> >
> >> your use of the term "region" is different than the way it's described
> >> in the intro doc. what you call a "region" below, we would call a
> >> "region domain."
> >
> > a "region domain" is the smallest possible partition???
> > I thought a region is a single 'sim' (in SL those 256x256 m^2 areas)
> 
> yes, a region is the smallest possible partition that is defined in
> OGP/VWRAP.

So far so good...

The rest seems irrelevant as it just says "SL isn't VWRAP", I know that.

We're trying to define terms to use in our communication within the group,
or even just on this list. I've said that many times now.

[irrelevant...
> but OGP/VWRAP regions are not limited to SL's 256x256
> geometry. also, we're not trying to force the use of "parcels" and
> "estates" as part of OGP/VWRAP. they are, of course, an integral part
> of our billing process, so Linden will still support them, and if
> people think we need to publicly define the interface and definition
               ^^__ this group?
> of these terms, we probably would.
> 
> but we don't think it's a requirement for non-second life regions to
      ^^__ Linden Lab?
> support our billing infrastructure, so it's probably going to be
> defined as a distinct set of resources/interfaces available on linden
> region domain(s).
> 
> later on if everyone thinks such a thing SHOULD go in the protocol,
> maybe, but i don't think people will.
...]

Okay, so from your only (first) line, I'd guess that -yes- the
term "region" means "the smallest partition" (that can be run
one per host).

> >> what we call a "region" is the set of data used to
> >> represent a collection of adjacent points in the virtual world. i'm
> >
> > you lost me there, comparing it with SL (PLEASE! just for clarity!),
> > do you mean something smaller than 256x256 meter or something larger
> > with endless sea as boundary?
> 
> for the purposes of OGP/VWRAP, a region is some data with a couple of
> well defined interfaces queried by clients (either client applications
> running on users' systems, other VWRAP servers or other information
> services (read web applications.) one aspect of a region is it's
> shape. the region may choose to define their shape as 256x256m if they
> want, and most currently deployed SL regions will likely retain that
> shape for the indefinite future. but there's no reason someone else
> could define a region to be 128x128m or 512x512m or decide to use an
> arbitrary 3d shape to define the bounds of the region.

Ok. This is what I thought, and my proposal for "REGION" was correct then.

> and though VWRAP will define the concept of a region and SL will
> define regions to be 256x256m in the near term, this doesn't mean you
> can't define "sub-regions" or "super-regions" or "sectors" or "map
> grids" or "stellar cartography instances" in your region domain.

I'd call that "inter-world" protocol, which is not relevant for this group:
A notition of "super-regions" etc will not be part of VWRAP.

> >> hoping that the verbiage in the draft charter makes it clear that
> >> services that export information about the region or provide an
> >> interface to modify the region's state go through a single region
> >> specific URI. the "simulator" is the server process that maintains the
> >> region's state and processes service requests. the "simulator host" or
> >> "region host" is the machine itself that the simulator process runs
> >> on.
> >
> > I thought you just said that was a region domain
> 
> no. a "region" is the object graph. the "simulator" is the process
> that implements the protocol. the "region domain" is the collection of
> regions "owned" by one organization. the "region host" or "simulator
> host" is the machine on which the simulator runs.

Great! Progress! :)
You never said that before (while I am on this list).

So, in the words that I used before,
  "REGION DOMAIN": set of REGION's run by one administration.

> >> further, a "domain" is a collection of resources administered by a
> >> single entity. thus a "region domain" is a collection of regions that
> >> are run by the same entity, and presumably _could_ be governed by the
> >> same terms of service, or more importantly to us, could potentially be
> >> considered a single end entity in the trust model.
> >
> > you said "what we call a "region" is the set of data used to
> > represent a collection of adjacent points in the virtual world"
> > and "a "region domain" is a collection of regions..."
> > Thus a region domain is adjacent? Or not?
> 
> a region domain is a collection of collections. the protocol does not
> flatten collections.
> >> we haven't put the term "adjacent region" into the doc, and now that i
> >> see you talking about it, i think it was an oversight not to. or
> >> rather, maybe just to talk about "adjacency" in general. for people
> >> who are unfamiliar with SL, adjacent regions are simply regions that
> >> are next to each other in the geometry of the virtual world. in second
> >> life, a region communicates with adjacent regions so the original
> >
> > see? a region IS a sim! Then that is the smallest partition, no??
> > (partition as in 'able to run on separate hardware'; definitely not
> > talking about parcels)
> 
> huh? a region is a region and a sim is a sim.

Would you mind explaining the difference?

> >> region can tell the client the state of assets it's managing, if the
> >> client needs to know about it and policy says the client can access
> >> that information. *whew* in SL, the term "island" sometimes means
> >> regions that have no adjacent regions (i.e. - they're out in the
> >> virtual ocean, all by themselves) or about a virtual landscape that
> >> looks like an island. (obviously, the former is more interesting to
> >> this group than the latter at this moment.)
> >
> > so we have consensus there ((a set of) regions that have no adjacent regions)
> > I just add that it's run by a single administration
> 
> yeah. it's thought that a region will have one root administrator, and
> may have 0 or more adjacent regions.
> 
> that being said.. we have to be careful when we define who gets to
> administer regions in region domains or any subordinate organizations
> the region or region domain introduces. i don't want to define things
> in a way that OSGrid has problems. and we're going to retain the
> feature of our system that estate owners can do things that normal
> users can't. but we don't want to force everyone to adopt this model,
> so we're not pushing for it to be in the spec, 'cause we really think
> there are people out there who don't want to be burdened with
> artifacts of our billing model.

When I say "administration" I mean the people owning the machines
that a server runs on, NOT "estate managers" and not even those
who pay (rent) the sims.

To compare with Second Life: the only administration that exists
here is "Linden Lab".

So, again, my proposal is to use "ISLAND" for a set of adjacent REGION's
with no other adjacent regions that is run by a single administration.
And to talk about "CONTINENT" when more than one administration is
involved. I'm not saying we have to publically define this; I'm trying
to make sure I will be understood when I use those terms in my future
posts.

> >> the terms "land" and "continent" are not defined in the spec. SL uses
> >> "continents" for administrative and (some) billing purposes. we are
> >> not trying to foist this aspect of SL off on the unsuspecting public.
> >> that is, it works well for us to divide things into continents, and if
> >> someone other than Linden wants to do this, good on ya. but, requiring
> >> that this be a part of the specification is not harmonious with our
> >> objective of not having people say bad things about us.
> >
> > no reason not to use the terms from now on on this list.
> 
> yes. there are reasons not to use them. they have no normative
> definition and asking people to accept artifacts of our billing model
> is asking for trouble.

There is no need for a normative definition to exist, and using a term
on this list has nothing to do whatsoever with asking people to
accept artifacts of your billing model.

> >> "galaxy" is also not defined in the spec, or by any of implementors
> >> who worked on OGP over the last 2 years.
> >
> > no reason not to use it on this list.
> 
> why not call it a cartographic set?

If you are happy with that, sure.
As I've said many times already: ANY term will do - just as long as you
will understand what I mean when I use it.

> >> "virtual world" is defined informally as discussed earlier on this
> >> list. i know morgaine frequently uses the term "region domain" to
> >> describe what we would call a "virtual world."
> >
> > Yes, Morgaine/Kari/me say: "virtual world" < "region domain", or so
> > we thought. You say: "region domain" < "virtual world", and still
> > there is no need to define these terms more clearly, right?
> 
> yes, but we don't have the need to define the term "virtual world."

we only use it thirteen times in the charter.

> >> "VWRAP Universe" is not defined now, and i'm generally loathe to
> >> introduce new terms, but i have to admit, i kinda like this one. but
> >> let's talk about it more later.
> >
> > not important
> 
> LOL. i say i like something and you assert it's irrelevant.
> 
> >
> >> about "MMOX Universe.." as far as i can tell, no one is working on
> >> MMOX currently, so we might want to say "non-VWRAP universe" to
> >> describe universes that are not VWRAPish.
> >
> > even less important
> 
> huh? you are trying to tell me we should define things that are not
> VWRAP as "non-VWRAP" instead of "MMOX" and i tell you there seems to
> be no one working on MMOX and you think this is unimportant? really?

There seems to be a very consistent misunderstanding between us.

> > Now please do the reverse: start with my descriptions and then
> > give terms that we can use ON THIS LIST - not in the protocol, or
> > drafts or whatever document - just here - so that we UNDERSTAND
> > eachother!
> >
> > Let me fill in what I THINK you have as term...
> >
> >> > A) A smallest partition
> >
> > I still think you call this 'region': in principle it is
> > possible to run every region on a different host/machine,
> > there is nothing smaller that could be run on a separate
> > machine.
> 
> i could care less how many machines it's run on. a region has a single
> URI used to request its services.

good enough for me. you DID misread my remark though.
Completely independent of whether it interests you, my definition holds,
and therefore was a correct attempt to get mutual agreement on what
region means.

> >> > B) A collection of adjacent regions run by a single administration
> >
> > you have no term... but we need one.
> > Make one up, or lets use 'island'
> 
> fine. you can call it an island. it is unimportant for the definition
> of the protocol. what is important is that regions have 0 or more
> adjacent regions and that regions are members of a region domain.

Well, I rather type "island" than "a collection of adjacent regions from one
region domain that have no other regions adjacent to it" every time :)

> >> > C) A collection of adjacent regions's run by different administrations
> >> >   (which very likely use the same TOS etc)
> >
> > idem / 'continent'
> 
> again. feel free to use whatever terminology you want to use.

Great! 'continent' then now will mean (if I use it): "a collection of
adjacent regions from one or more region domain that have no other
regions adjacent to it"

Note that with this definition an island IS a continent.

Both are, indeed, not very important though. I only introduced them
to 'build up' to a (this way) clear description of the next two terms,
what this is all about.

> >> > D) A collection of continent's that are not adjacent but still fall
> >> >   under the same TOS, likely use the same inter-world protocols
> >> >   and organisation-specific extensions etc (likely, they will
> >> >   have their own website and their own Abuse Report team etc).
> >
> > *** THIS IS THE REASON THAT WE HAVE A PROBLEM WITH THE CHARTER ***
> > because: you don't HAVE a term for this!
> 
> well. sorry you don't want to play with us.

Excuse me?

Are you the chairwoman of this group by the way? Is there a way
to vote about who should lead this group? Goes we're getting into
a dead end again and again and in the end you're just going to
sent that charter to the IETF, right? Cause "Carlo is not a part
of the group, therefore we have consensus". I didn't want to play
with you, after all.

> > That collapses D and E into one, and that is unacceptable.
> >
> >> > E) A collection of Virtual World's that have totally different
> >> >   administrations and possibly different TOS etc, but which
> >> >   interoperate (ie, you can pass on a Landmark of one VW to
> >> >   a person you meet in another VW).
> >
> > You consistently call this 'virtual world'
> 
> we do not use the term "virtual world" in a normative fashion.

You surely have your ways to make someone furious of frustration :(

I think it's better if this group FAILS to create a working group
at this point. It is simply not working.

-- 
Carlo Wood <[e-mail]>