Subject: [vwrap] [wvrap] Simulation consistency

From: Vaughn Deluca <[email-masked]>
Date: Sat, 2 Apr 2011 00:17:31 +0200

This is a question i discussed with Morgaine off-list a while ago (I
intended to send it to the list but pushed the wrong button...) I
think we need to address this problem, and decide how to deal with it.

 In Davids deployment draft, section 7.3.1.1 an overview is given van
ways to deliver content to the region. One way is only passing a
capability that allows access to (part of) the resource:
   	
	   7.3.1.1.  Content delivery models
	   A range of possible represenations can be passed to a region for
	   simulation. [...] The other end of the delivery spectrum involves passing
           only a URI or capability used to access the rendering
information and a
           collision mesh,and related data for physical simulation.
	   In such a model, the client is responsible for fetching the additional
	   information needed to render the item's visual presence from a separate
	   service.  This fetch can be done *under the credentials of the end user*
           viewing the material [my emphasis--VD] , and divorces the
simulation from
           the trust chain needed to manage content.  Any automation
is done on a
           separate host which the content creator or owner trusts,
interacting with the
           object through remoted interfaces.

 I can see the need for such a setup, however, i feel we are
unpleasantly close to a situation were the coherence of the simulation
falls apart.
In this deployment pattern the region advertises the presence of the
asset, and *some* clients will be able to get it as expected, while
-based on the arbitrary whims of the asset service- others might not.

My hope would be that after the asset server provides the region with
the capability to get the asset, it gives up control. That would mean
that if the client finds the inventory server is unwilling to serve
the content - in spire of the region saying it is present-, the client
should be able to turn around ask the *region* for the asset, (and get
is after all).

 If that is not the case, -and there are probably good reasons for the
deployment pattern as described-  shouldn't we *warn* clients that the
region might be inconsistent, so the users behind the client can vote
with their feet, (or take the risk)?

--Vaughn

---

From: Morgaine <[email-masked]>
Date: Sat, 2 Apr 2011 04:55:40 +0100

Every design choice results in a trade-off, Vaughn, improving one thing at
the expense of something else.  If every time we offered a service we had to
inform its users about the downsides of all the trade-offs we have made,
they would have an awful lot to read. ;-)

The specific trade-off that you are discussing is no different.  A region
that proxies all content has the "benefit" of acquiring control from the
asset servers over the items in the region, so that it can ensure that
everyone in the region not only obtains the items but obtains the
*same*items as everyone else.  That does indeed provide a greater
guarantee of
consistency than a deployment in which the region only passes asset URIs to
clients who then fetch the items from asset services separately.  As always
though, it's a trade-off, since the proxied design has very poor scalability
compared to the distributed one.

If we're going to warn users of the potential for inconsistency in the
distributed deployment as you suggest, are we also going to warn them of
non-scalability in the proxied one?  I really don't see much merit in the
idea of warning about design choices.  Many such choices are technical, and
the issues are quite likely to be of little interest to non-technical users
anyway.  In any case, the better services are likely to provide such
information in their online documentation, I would guess.

You mentioned users "voting with their feet" or choosing to accept the risk
of inconsistency.  Well that will happen anyway, when services fail and
users get annoyed.  If some asset services refuse to send the requested
items to some users, those services will get a bad reputation and people
will choose different asset services instead.  Likewise, if a world service
proxies everything and so it can't handle a large number of assets or of
people, users will get annoyed at the lag and will go elsewhere.  This user
evaluation and "voting with their feet" happens already with online services
all over the Internet, and I am sure that this human process will continue
to work when the services are asset and region services.

Back in September 2010, I wrote this post which proposes that we use in
VWRAP a form of asset addressing that provides massive scalability at the
same time as a very high degree of resilience --
http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .  It is
based on the concept of the URI containing a host part and a hash part,
where the hash is generated (once, at the time of storage to the asset
service) using a specified digest algorithm over the content of the asset
being referenced.  You may wish to note that if this design were used, the
failure of an asset service to deliver a requested item would result in a
failover request for the item to one or more backup services, using the same
hash part but with a different host address.

This can go some way towards overcoming the problem that you think might
occur when assets are fetched by clients from asset services directly.
Although it won't help when the missing item is available from only a single
asset service, it will help in many other cases, and it will compensate for
service failures and network outages automatically at the same time.

PS. This design for hash-based asset addressing is already being tested by
Mojito Sorbet in her experimental world and client.  It would give
VWRAP-based worlds an improved level of service availability, so I think it
should be a core feature of our protocol.

Morgaine.

===========================

On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca <[email-masked]>wrote:

> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: Morgaine <[email-masked]>
Date: Sat, 2 Apr 2011 06:31:30 +0100

Further to my last post, it's worth noting that if you find that you suffer
poor quality behavior from a particular asset service and it is breaking the
consistency of your simulation, with hash-based item addressing you can also
automatically use an alternative asset service *in preference* to the one
specified in a given URI.

Your client could be configured to attempt the item fetch at a known good
quality asset service *first* (perhaps one that you paid to use because of
its better service), automatically, and maybe even dynamically depending on
the type of item.

The scheme has a long list of benefits, and overcoming (to some extent) poor
quality asset services is just one of them.

Morgaine.

===================

On Sat, Apr 2, 2011 at 4:55 AM, Morgaine <[email-masked]>wrote:

> everyone in the region not only obtains the items but obtains the *same*items as everyone else.  That does indeed provide a greater guarantee of

---

From: Vaughn Deluca <[email-masked]>
Date: Sat, 2 Apr 2011 12:26:08 +0200

Morgaine, Meadhbh,

Thanks for the answers, but i see that i have not been clear enough.
I think the protocol should demand certain things to prevent the
 deterioration of the simulation to an unacceptable level. We need to be
more precise to prevent problems and i think we can.

I was arguing from the perspecive of a region service without making that
explicit. Note i was *not* advocating the region proxies everything, just
that it lives up to its promises about object presence. Also note that i do
 *not* always have the option to pick another high quality asset service,
since I normally do not own the assets. I will use Prokofy as an example
just for the fun of it.  He is highly worried about content theft, so (in
the unlikely case he wants to start selling stuff outside of SL) he might
use this deployment pattern.  Assume he sells wonderful sexy dresses to two
customers, that can only be fetched from his own asset service for
rendering. Both customers go off to "Vaughns highly immersive world" were a
party is given.  My region receives some physics properties of the dresses
for simulation and an address of Proks asset service for high-res details
and textures. In this case the region does not even get the capability to
fetch the assets, just a link to the asset service and its up to viewer to
request the details and show credentials to get them. The two girls meet,
both their viewers request the details of the other dress, and Proks asset
service grants those requests. They girls admire their dresses and
compliment each other with their good taste. Now when i arrive and my viewer
request the dress details, Prok's asset service recognises me as the
copyleftists that i am. It refuses to serve the asset details -and depending
on my viewers behaviour i might get to view two girls in sexy underwear -or
wearing even less- instead of party dresses. From a consistency point of
view this is a highly undesirable situation, it breaks immersion, and
depending on the circumstances might also be embarrassing to the people
involved.

The key question is if we want to allow this situation to arise within VWRAP
compliant worlds.
I would like to argue that the region *should* get the capability to fetch
all details. In other words, Prokofy would have to give up some control over
the asset in case he allows it to be used by my region. Note that this does
not mean that the region *has* to proxy the asset, just that in case the
asset service refuses to serve a client it does not like, the region can
insist on delivery  based on the capability it originally got. If that fails
Proks asset service can not be called VWRAP compliant.

If Prokofy does not want to relinquish  that level of control, fine, it is
his right not to, but in that case the dresses should not be allowed to get
into my region in the first place.  If people visit my region and find
themselves naked in the eyes of some others *I* will get the blame.  As
Morgaine says, the technical details of my innocence will not convince the
general public. So I want methods to prevent breaking my highly emergent
world as much as possible.
My proposal would be that the whatever the region gets MUST be guaranteed by
protocol to be delivered to  anybody within the region requesting it. If the
asset service does not want to serve a cryptocomunist copyleftist, fine, but
IF it has given the region a capability, it MUST serve the full asset to be
VWRAP compliant. Its *my* choice as a region deployer to download the full
asset to be able to guarantee region consistency if I want to. I will try to
avoid that as much as possible, but if my customers complain, i will be
forces to start doing this for certain asset services that i know show
discriminatory behaviour against for instance copyleftist.

Finally Morgaine, you keep hammering on the fact that proxying by the region
does not scale. (I tend to disagree, but that is beside the point here). I
do agree the asset should not be needlessly transfered, but i strongly feel
we must insist in the protocol on transferring the *rights* to view the
asset. If that leads to to the region not getting the asset at all, so be
it, it can warn visitors that their assets will not be visible and even
offer to serve simple replacements (1). This in turn will encourage the end
users to avoid this type of asset service, and Prokofy will go out of
business, as should be the case given the behaviour of the service. And if
he pulls it off, thats fine with me also, as long as i do not have to suffer
from it due to lack of rigour in the protocol specs.

So, in summary, I very well see that there is no way to enforce consistent
serving behaviour but it should at least be clear that it is non-standard
and not conform the protocol. The way I am understanding you now, your
argument seems to be just one step to far in the direction of anarchy.
Or am i misreading you?

--Vaughn

(1) I just realise that the region might cheat and advertise its own asset
brands claiming the competitions assets  could not be rendered... Oh well,
one might hope that if there is enough choice in worlds such regions will be
forced  out of business as well.

On Sat, Apr 2, 2011 at 7:31 AM, Morgaine <[email-masked]>wrote:

> The scheme has a long list of benefits, and overcoming (to some extent)
> poor quality asset services is just one of them.
>
>
> Morgaine.
>
>
>
>
>
> ===================
>
>
>> You mentioned users "voting with their feet" or choosing to accept the
>> risk of inconsistency.  Well that will happen anyway, when services fail and

---

From: Morgaine <[email-masked]>
Date: Sat, 2 Apr 2011 13:58:11 +0100

Vaughn, I think you've described the situation perfectly, and no, I doubt
that you have been misunderstood, at least not by me.  (Admittedly we did
discuss this issue in depth in emails previously, but I think you have
presented it so clearly that I am sure that everyone understands the point
you are making.)

The problem however is that you are asking the impossible, namely that one
party (the region provider) should have policy control over another (the
asset service provider).  As David has said on many different occasions and
in various different ways, this attempt at policy export just won't work in
practice, because each party is "sovereign" over its own service, so to
speak.  At best you can only recommend or hope for sensible behavior by all,
and if there is a legal relationship between the parties then presumably the
pressure of law can help as well.

The big commercial players may well take a legal route, but certainly not
the thousands (or millions) of participants in a flourishing metaverse of
community VWs that is spread across the whole planet in countless
jurisdictions.  What they will have to rely on is either something that
works by technical means, or else simply on *best effort* by all --- in
other words, exactly the same means by which the quality of services on the
Internet is "assured", using the word loosely. ;-)

Technical means of assuring what you want are in your grasp --- you can
proxy everything, as we said before, but only at a large cost to your
scalability because your region will now have to transport enormously more
data to clients.  Still, that may be a tradeoff that you are willing to make
if you are so keen on offering many 9's worth of simulation consistency and
don't expect your region to scale much.

That choice would be up to you, and it's a perfectly excellent choice to
make because you have a requirement that needs to be met, but you cannot
force that choice on everybody.  I predict that many commercial providers
will be more interested in scalability than in 100% consistency because
there is money to be made from large numbers of visitors to your world, and
so they might well be happy to tolerate the occasional hiccup in external
asset services which scale so well.  For non-commercial world operators
though, the normal best-effort "guarantees" are likely to be entirely
sufficient, particularly if we use hash-based addressing so that asset
access has multiple failover paths.

I do think that you have overstated the magnitude of the problem, however.
Yes, it will be possible for things to break if asset service operators
purposely reject some connections, but how widespread is this likely to be?
Just think of the consequences of doing so.  If I buy a dress and TP to a
holiday world and I arrive minus dress, do you think I will buy more
clothing that is served from that same asset service?  Not very likely.
Seller beware!

I expect ranking sites that rank both community and commercial asset
services to appear, showing service uptime and delivery speed and
reliability metrics, just like there are ranking sites for ISPs today
showing speed and availability.  The Internet communities are very good at
doing that sort of thing, and it applies pressure on service providers very
nicely.  "Vote with your feet" will have every chance of working well.

This issue really highlights how important the concept of "deployment
patterns" is in VWRAP.  It's easy to see that requirements are going to vary
widely between different providers, and we will have to ensure that
deployments are available that cater for all the common scenarios, of which
yours is clearly one.

Morgaine.

====================

On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca <[email-masked]>wrote:

> The key question is if we want to allow this situation to arise within
> VWRAP compliant worlds.
> My proposal would be that the whatever the region gets MUST be guaranteed
> by protocol to be delivered to  anybody within the region requesting it. If
> the asset service does not want to serve a cryptocomunist copyleftist, fine,
> but IF it has given the region a capability, it MUST serve the full asset to
> be VWRAP compliant. Its *my* choice as a region deployer to download the
> full asset to be able to guarantee region consistency if I want to. I will
> try to avoid that as much as possible, but if my customers complain, i will
> be forces to start doing this for certain asset services that i know show
> Finally Morgaine, you keep hammering on the fact that proxying by the
> region does not scale. (I tend to disagree, but that is beside the point
> here). I do agree the asset should not be needlessly transfered, but i
> strongly feel we must insist in the protocol on transferring the *rights* to
> view the asset. If that leads to to the region not getting the asset at all,
> so be it, it can warn visitors that their assets will not be visible and
> even offer to serve simple replacements (1). This in turn will encourage the
> end users to avoid this type of asset service, and Prokofy will go out of
>> Further to my last post, it's worth noting that if you find that you
>> suffer poor quality behavior from a particular asset service and it is
>> breaking the consistency of your simulation, with hash-based item addressing
>> you can also automatically use an alternative asset service *in
>> preference* to the one specified in a given URI.
>>
>> quality asset service *first* (perhaps one that you paid to use because
>> of its better service), automatically, and maybe even dynamically depending
>> on the type of item.
>>
>>> Every design choice results in a trade-off, Vaughn, improving one thing
>>> at the expense of something else.  If every time we offered a service we had
>>> to inform its users about the downsides of all the trade-offs we have made,
>>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .  It
>>> is based on the concept of the URI containing a host part and a hash part,
>>> PS. This design for hash-based asset addressing is already being tested
>>> by Mojito Sorbet in her experimental world and client.  It would give

---

From: Morgaine <[email-masked]>
Date: Sat, 2 Apr 2011 16:09:49 +0100

Vaughn, I left your final (and very important) point for the end of my
response, and then I fired off my email without addressing it ...  Sorry. :P

On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca <[email-masked]>wrote:

>  So I want methods to prevent breaking my highly emergent world as much as
> possible.
>

Yes indeed!!!

You have a perfectly reasonable requirement for the service that you want to
operate, and you need some means of meeting it.  I agree with that
wholeheartedly.  I only begin to disagree when you hint that your
requirement must be imposed on everyone, whether they want it or not.  That
I cannot support, and I expect that you did not mean it that way anyway.
After all, some of my requirements are probably not of interest to you
either, and you would not wish me to impose them on you.  It cuts both ways.

So, how can we enable you to offer a service with many 9's of simulation
consistency, without imposing that requirement on those who prefer a
different trade-off?  You hinted at the solution yourself, so I'll merely
elaborate on it.  You wrote:

> all details. [...]  Note that this does not mean that the region *has* to
> proxy the asset, just that in case the asset service refuses to serve a
> client it does not like, the region can insist on delivery  based on the
> capability it originally got.
>

Perfect.  All you need then is an optional query in the protocol that allows
a region to ask each asset service referenced by assets carried by newly
arriving avatars the following question:

QUERY: "*Do I have your permission to fetch from your asset service the
assets normally reserved for client fetches, and to distribute these assets
to clients directly in the (unexpected) event that I want to?*"

That easily maps to an optional capability request of course.  If the asset
service answers "No" to you, then you can deny the incoming avatar entry to
your region, returning a status that indicates

RESPONSE: "*Asset service X referenced by asset Y does not meet the
re-distribution requirement requested for entry to region Z*".

Your requirement is then satisfied (I believe) without imposing that
requirement on a region operator who does not need it because they desire a
different trade-off.  Those who don't have your requirement simply won't
request the capability.

For example, it would be pointless to even ask an asset service founded
entirely around Creative Commons assets that question, since all CC content
is perpetually and non-revocably redistributable by anyone and to anyone.
By not issuing the query we can save ourselves the round-trip time and allow
faster entry to the region.

Would something like that get the nod from you?

PS. You need to note that when an asset service answers "Yes" to your query,
this does not mean that it will necessarily honor its promise when you
actually attempt to fetch items.  David's very important point about
independent parties not having control over each other applies here.  You
can at most hope that it will behave well, and perhaps test the promise by
fetching something.  However, if you truly want as many 9's of consistency
as is obtainable then you will have to fetch all the assets yourself prior
to allowing entry to the avatar, and that would be a dreadful overhead.
Most people will probably settle for "*best effort*" approaches, which are
quite likely to succeed.

Morgaine.

=====================

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 02 Apr 2011 08:36:11 -0700

Your hash/digest method is similar to basic REST and what I already 
implemented. Icesphere already has implementations and methods and even 
furthers them with burst modes so where there is no worry to have a URI 
for each asset. The URI can specify a list of assets or single asset 
(content varies as such), which can be returned immediately or when each 
is ready for transfer, individually. Uses LLIDL with proposed changes:

Everything is documented here: 
http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Inventory
(Last edited that doc in August 2010 & Icesphere's implementation has 
been used for awhile since then)

Morgaine wrote:
> Back in September 2010, I wrote this post which proposes that we use 
> in VWRAP a form of asset addressing that provides massive scalability 
> at the same time as a very high degree of resilience -- 
> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .� It 
> is based on the concept of the URI containing a host part and a hash 
> part, where the hash is generated (once, at the time of storage to the 
> asset service) using a specified digest algorithm over the content of 
> the asset being referenced.� You may wish to note that if this design 
> were used, the failure of an asset service to deliver a requested item 
> would result in a failover request for the item to one or more backup 
> services, using the same hash part but with a different host address.
>

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Carlo Wood <[email-masked]>
Date: Sat, 2 Apr 2011 19:08:53 +0200

On Sat, 2 Apr 2011 16:09:49 +0100
Morgaine <[email-masked]> wrote:
> That easily maps to an optional capability request of course.  If the
> asset service answers "No" to you, then you can deny the incoming
> avatar entry to your region, returning a status that indicates
> 

At which point, as a user, I'd like to have the option to
detach / take off (replace) whatever I'm using from asset
service X, rather than to completely be banned from entering
the region.  If the result is that I look aweful, then the
only requirement I have is that I see the same thing as
others, after I can I make the decision to either avoid using
asset server Y for future purchases, or to avoid entering
this region.

-- 
Carlo Wood <[email-masked]>

---

From: Izzy Alanis <[email-masked]>
Date: Sat, 2 Apr 2011 14:05:46 -0400

> As always though, it's a trade-off, since the proxied design has very poor scalability compared to the distributed one.

I don't agree with that... If a user enters a highly populated region,
every other client is going to (could and should be trying to) hit the
asset server(s) for the assets that the user is wearing (assuming
they're not cached locally).  Every asset server has to be scaled up
to the point that it can handle that load from all over...

If I'm hosting a region that supports 10s of thousands of simultaneous
users (thinking of the future), I already have to scale to meet that
demand. If the region is proxying the assets, then, yes the region has
to be scaled to meet that asset demand too, but it already has to be
scaled to meet other demands of being a region server... and why is
scaling those asset proxy services hard?  It's going to cost $, but is
not technically challenging. So, if I want to host a region like
that... sure it will cost me, but the simulation will be consistent
and users will be able to participate equally, regardless of the
capabilities of their individual asset services.

On Fri, Apr 1, 2011 at 11:55 PM, Morgaine
<[email-masked]> wrote:
> everyone in the region not only obtains the items but obtains the same items
> as everyone else.  That does indeed provide a greater guarantee of

---

From: Morgaine <[email-masked]>
Date: Sat, 2 Apr 2011 19:31:52 +0100

Hash-based addressing is very different to UUID-based addressing as used in
SNOW-375, so I expect there is some misunderstanding of how hash digests are
applied in this scheme,

The universal address of the item is the hash digest over the data of the
item using a specified digest algorithm, and is not a UUID.  It is invariant
regardless of who computes it, although it would normally be computed only
once by the asset service at the time that the item is being stored in the
service.  All asset services everywhere will use the same digest as an
address for this item, because the digest algorithm is specified.

Data that is addressed and indexed in this way can of course be used in a
REST architecture with appropriate design, but because hash digests are not
UUIDs, there is quite a different semantic to it.  A UUID cannot be used as
a shared cache index in a multi-world architecture, because identical
content in N different worlds will have different UUIDs associated with it
in each world.  In contrast, identical content in N different worlds will
have an identical hash in every world, and therefore only a single storage
entry is needed in a multi-world cache.

The effect of this is dramatic.  Every time that an Object ARchive is loaded
to populate a new region, this can generate another several hundred thousand
(and soon, millions) of new assets which in a UUID-addressed scheme will
typically just grow the asset storage without bound.  In a hash-addressed
scheme, that OAR can be loaded a million times and the asset data storage
doesn't increase by 1 byte, neither in the asset server, the region, nor in
client caches.  Only metadata storage need grow for repeated assets in asset
services, but it's not even needed in client-side caches, so the benefits
are huge.

A nice mental image that really brings this home is that of grass patches
and trees and other common environmental objects reused in countless worlds
across the metaverse, yet requiring no downloads at all as you tour around
the worlds because visiting just one world has populated your persistent
cache with those common items already.

This can represents storage savings of thousands or even millions to 1, and
corresponding time savings too because the remote fetches from asset
services are avoided entirely.  The impact of this scheme on user experience
can be expected to be outstanding even in today's humble beginnings, and
much more so as the metaverse blooms.  It's the scheme with the best
performance and scalability of any we have examined so far.

UUID-based asset storage does not have these excellent properties, nor the
other advantages that I have described previously.

Morgaine.

=====================

On Sat, Apr 2, 2011 at 4:36 PM, Dzonatas Sol <[email-masked]> wrote:

> furthers them with burst modes so where there is no worry to have a URI for
> each asset. The URI can specify a list of assets or single asset (content
> varies as such), which can be returned immediately or when each is ready for
> transfer, individually. Uses LLIDL with proposed changes:
>
> (Last edited that doc in August 2010 & Icesphere's implementation has been
> used for awhile since then)
>
>
>
> Morgaine wrote:
>
>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .� It is
>> being referenced.� You may wish to note that if this design were used, the

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 02 Apr 2011 12:00:41 -0700

Again, you assumed too much and narrowed it down too some straw-man 
argument of UUID only. There are many ways to cache.

SNOW-375 has the functionality for hash-based, if you want to further 
the public/private implementation of URIs. The functionality for 
private-URI being based on public URIs (as documented) is just cache and 
redirect, not much different from hash-based as you describe. I just 
haven't implemented login option create a digest for private URIs (as 
noted in the documentation section about "feature freeze"). Purposely 
waited...   (and I'm in 
multi-point/multi-client/full-duplex/anti-exploit mindset )...

...and waited...

Despite my reasons to wait and do other things, open virtual worlds vs 
legacy...

I'll lean more towards organic and analog based types then identical 
assets, especially if virtual worlds include real world peripherals.

Morgaine wrote:
> Hash-based addressing is very different to UUID-based addressing as 
> used in SNOW-375, so I expect there is some misunderstanding of how 
> hash digests are applied in this scheme,
>
> The universal address of the item is the hash digest over the data of 
> the item using a specified digest algorithm, and is not a UUID.  It is 
> invariant regardless of who computes it, although it would normally be 
> computed only once by the asset service at the time that the item is 
> being stored in the service.  All asset services everywhere will use 
> the same digest as an address for this item, because the digest 
> algorithm is specified.
>
> Data that is addressed and indexed in this way can of course be used 
> in a REST architecture with appropriate design, but because hash 
> digests are not UUIDs, there is quite a different semantic to it.  A 
> UUID cannot be used as a shared cache index in a multi-world 
> architecture, because identical content in N different worlds will 
> have different UUIDs associated with it in each world.  In contrast, 
> identical content in N different worlds will have an identical hash in 
> every world, and therefore only a single storage entry is needed in a 
> multi-world cache.
>
> The effect of this is dramatic.  Every time that an Object ARchive is 
> loaded to populate a new region, this can generate another several 
> hundred thousand (and soon, millions) of new assets which in a 
> UUID-addressed scheme will typically just grow the asset storage 
> without bound.  In a hash-addressed scheme, that OAR can be loaded a 
> million times and the asset data storage doesn't increase by 1 byte, 
> neither in the asset server, the region, nor in client caches.  Only 
> metadata storage need grow for repeated assets in asset services, but 
> it's not even needed in client-side caches, so the benefits are huge.
>
> A nice mental image that really brings this home is that of grass 
> patches and trees and other common environmental objects reused in 
> countless worlds across the metaverse, yet requiring no downloads at 
> all as you tour around the worlds because visiting just one world has 
> populated your persistent cache with those common items already.
>
> This can represents storage savings of thousands or even millions to 
> 1, and corresponding time savings too because the remote fetches from 
> asset services are avoided entirely.  The impact of this scheme on 
> user experience can be expected to be outstanding even in today's 
> humble beginnings, and much more so as the metaverse blooms.  It's the 
> scheme with the best performance and scalability of any we have 
> examined so far.
>
> UUID-based asset storage does not have these excellent properties, nor 
> the other advantages that I have described previously.
>
>
> Morgaine.
>
>
>
>
>
> =====================
>
> On Sat, Apr 2, 2011 at 4:36 PM, Dzonatas Sol <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Your hash/digest method is similar to basic REST and what I
>     already implemented. Icesphere already has implementations and
>     methods and even furthers them with burst modes so where there is
>     no worry to have a URI for each asset. The URI can specify a list
>     of assets or single asset (content varies as such), which can be
>     returned immediately or when each is ready for transfer,
>     individually. Uses LLIDL with proposed changes:
>
>     (Last edited that doc in August 2010 & Icesphere's implementation
>     has been used for awhile since then)
>
>
>
>     Morgaine wrote:
>
>         Back in September 2010, I wrote this post which proposes that
>         we use in VWRAP a form of asset addressing that provides
>         massive scalability at the same time as a very high degree of
>         resilience --
>         http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html
>         .� It is based on the concept of the URI containing a host
>         part and a hash part, where the hash is generated (once, at
>         the time of storage to the asset service) using a specified
>         digest algorithm over the content of the asset being
>         referenced.� You may wish to note that if this design were
>         used, the failure of an asset service to deliver a requested
>         item would result in a failover request for the item to one or
>         more backup services, using the same hash part but with a
>         different host address.
>
>
>
>     -- 
> ------------------------------------------------------------------------
>

--

---

From: Morgaine <[email-masked]>
Date: Sat, 2 Apr 2011 20:15:57 +0100

I have no doubt that you *could* adapt SNOW-375 to hash-based addressing,
but that is not what SNOW-375 currently describes, so the point is moot.

Morgaine.

=====================

On Sat, Apr 2, 2011 at 8:00 PM, Dzonatas Sol <[email-masked]> wrote:

> SNOW-375 has the functionality for hash-based, if you want to further the
> public/private implementation of URIs. The functionality for private-URI
> being based on public URIs (as documented) is just cache and redirect, not
> much different from hash-based as you describe. I just haven't implemented
> login option create a digest for private URIs (as noted in the documentation
> section about "feature freeze"). Purposely waited...   (and I'm in
>> Hash-based addressing is very different to UUID-based addressing as used
>> in SNOW-375, so I expect there is some misunderstanding of how hash digests
>> are applied in this scheme,
>>
>> loaded to populate a new region, this can generate another several hundred
>> thousand (and soon, millions) of new assets which in a UUID-addressed scheme
>> will typically just grow the asset storage without bound.  In a
>> hash-addressed scheme, that OAR can be loaded a million times and the asset
>> data storage doesn't increase by 1 byte, neither in the asset server, the
>> region, nor in client caches.  Only metadata storage need grow for repeated
>> assets in asset services, but it's not even needed in client-side caches, so
>> the benefits are huge.
>>
>> This can represents storage savings of thousands or even millions to 1,
>> and corresponding time savings too because the remote fetches from asset
>> On Sat, Apr 2, 2011 at 4:36 PM, Dzonatas Sol <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>    --     --- https://twitter.com/Dzonatas_Sol ---

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 02 Apr 2011 12:38:45 -0700

I have no doubt that people could publish how, where, and why exploits 
exist, yet most of these are obvious (or become obvious) when 
keen-enough peeps actually implement  (and even re-implement) those 
ideas that sound great on paper with reasons given (limited from real 
world execution).

Moot? "Use-cases are under review..." -- 
http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375#Resources_.26_Capabilities

Of course, I'm not gonna describe how, where, and why... nor further 
implement such obvious exploits.

I'm surprised for how much you argued about trust and security.

Yes, I could expand the URI lookup cache to handle security by 
obscurity. Ok, moot point now.

Morgaine wrote:
> I have no doubt that you /*could*/ adapt SNOW-375 to hash-based 
> addressing, but that is not what SNOW-375 currently describes, so the 
> point is moot.
>
>
> Morgaine.
>
>
>
>
> =====================
>
> On Sat, Apr 2, 2011 at 8:00 PM, Dzonatas Sol <[email-masked] 
>     Again, you assumed too much and narrowed it down too some
>     straw-man argument of UUID only. There are many ways to cache.
>
>     SNOW-375 has the functionality for hash-based, if you want to
>     further the public/private implementation of URIs. The
>     functionality for private-URI being based on public URIs (as
>     documented) is just cache and redirect, not much different from
>     hash-based as you describe. I just haven't implemented login
>     option create a digest for private URIs (as noted in the
>     documentation section about "feature freeze"). Purposely waited...
>       (and I'm in multi-point/multi-client/full-duplex/anti-exploit
>     mindset )...
>
>     ...and waited...
>
>     Despite my reasons to wait and do other things, open virtual
>     worlds vs legacy...
>
>     I'll lean more towards organic and analog based types then
>     identical assets, especially if virtual worlds include real world
>     peripherals.
>
>
>     Morgaine wrote:
>
>         Hash-based addressing is very different to UUID-based
>         addressing as used in SNOW-375, so I expect there is some
>         misunderstanding of how hash digests are applied in this scheme,
>
>         The universal address of the item is the hash digest over the
>         data of the item using a specified digest algorithm, and is
>         not a UUID.  It is invariant regardless of who computes it,
>         although it would normally be computed only once by the asset
>         service at the time that the item is being stored in the
>         service.  All asset services everywhere will use the same
>         digest as an address for this item, because the digest
>         algorithm is specified.
>
>         Data that is addressed and indexed in this way can of course
>         be used in a REST architecture with appropriate design, but
>         because hash digests are not UUIDs, there is quite a different
>         semantic to it.  A UUID cannot be used as a shared cache index
>         in a multi-world architecture, because identical content in N
>         different worlds will have different UUIDs associated with it
>         in each world.  In contrast, identical content in N different
>         worlds will have an identical hash in every world, and
>         therefore only a single storage entry is needed in a
>         multi-world cache.
>
>         The effect of this is dramatic.  Every time that an Object
>         ARchive is loaded to populate a new region, this can generate
>         another several hundred thousand (and soon, millions) of new
>         assets which in a UUID-addressed scheme will typically just
>         grow the asset storage without bound.  In a hash-addressed
>         scheme, that OAR can be loaded a million times and the asset
>         data storage doesn't increase by 1 byte, neither in the asset
>         server, the region, nor in client caches.  Only metadata
>         storage need grow for repeated assets in asset services, but
>         A nice mental image that really brings this home is that of
>         grass patches and trees and other common environmental objects
>         reused in countless worlds across the metaverse, yet requiring
>         no downloads at all as you tour around the worlds because
>         visiting just one world has populated your persistent cache
>         with those common items already.
>
>         This can represents storage savings of thousands or even
>         millions to 1, and corresponding time savings too because the
>         remote fetches from asset services are avoided entirely.  The
>         impact of this scheme on user experience can be expected to be
>         outstanding even in today's humble beginnings, and much more
>         so as the metaverse blooms.  It's the scheme with the best
>         UUID-based asset storage does not have these excellent
>         properties, nor the other advantages that I have described
>         previously.
>
>
>         Morgaine.
>
>
>
>
>
>         =====================
>
>         On Sat, Apr 2, 2011 at 4:36 PM, Dzonatas Sol
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>         [email-masked] <mailto:[email-masked]>

--

---

From: Morgaine <[email-masked]>
Date: Sat, 2 Apr 2011 20:58:29 +0100

Izzy, when designing for scalability, the model to bear in mind is that of
seasoned virtual world travelers whose inventories contain assets from many
different worlds, those assets being served by many different asset
services.  Both worlds and asset services may include commercial, community,
and personal services, and as the metaverse grows, that set is highly likely
to become progressively less clustered and more diverse.

When those seasoned travelers click on an advertised VW link and perform an
inter-world teleport to one particular world's region to share an
experience, their "worn" assets (the only ones of interest to the region)
will contain references to asset services spread widely across the
Internet.  The fetches by the travelers' clients occur over many parallel
paths from clients to asset services, so one can reasonably expect reduced
network contention and reduced asset server loading because they are both
spread out over however many asset services are being referenced by the
overall set of assets in the region.

This is very different to the case of a proxying region, which would get
slammed for every asset worn by every avatar present.  In our current
architecture, regions run many different CPU-intensive tasks, including
physics simulation and server-side scripting, and absolutely cannot afford
to serve assets too unless your scalability requirements are very low
indeed, ie. just a few dozen avatars of today's kind.  We've hit the ceiling
already on region scalability done that way.  There is nowhere to go in that
direction at all beyond improving the code like Intel demonstrated, and that
work is subject to a law of diminishing returns.

This is why we have to go parallel, and I think you're wrong that it has to
cost much money.  As we spread the load across more and more asset services,
we are simply better utilizing all the hardware that's already out there on
the Internet, at least in respect of community and private resources.  But
add to the community and private resources the commercial asset services
that are likely to appear to exploit this opportunity, and not only will the
number of asset services leap, but the power of each one will rocket too,
because, after all, these businesses will be heavily optimized for the job.

As to why a world would want clients to access external asset services
instead of providing its own implementation, that's an easy question.  It
costs money to host a high performance and scalable asset service and a high
bandwidth network to handle the traffic.  A *lot* of money.  In contrast, it
costs a world nothing to let others serve the assets to clients.  And that
matters to the bottom line.

Morgaine.

======================

On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis <[email-masked]> wrote:

> > As always though, it's a trade-off, since the proxied design has very
> poor scalability compared to the distributed one.
>
> at
> risk
> is
> by

---

From: Morgaine <[email-masked]>
Date: Sat, 2 Apr 2011 21:12:29 +0100

You've provided a nice use case for client-side scripting there, Carlo. :-)

Indeed, your client could catch the error response code and switch worn
assets around in whichever way you wish to program or configure, and
resubmit the TP request transparently.  Lots of interesting possibilities
there.

Morgaine.

====================

---

From: Dahlia Trimble <[email-masked]>
Date: Sat, 2 Apr 2011 13:37:58 -0700

I can see another reason to allow the region to proxy assets, or at least
some service to proxy assets in the same domain as the region. "Sandboxed"
clients such as those which may be based on products as Unity3d or Adobe
Flash may be subject to a "same origin" policy (1), where they may be
restricted from making network connections outside of the domain from which
the application is served. There are workarounds but they may require
additional administration overhead for both asset and region service
providers, or a separate provider which proxies all traffic. I would hope a
VWRAP protocol definition would include the possibility of regions proxying
assets so such sandboxed clients can play a part in a VWRAP multiverse.

(1) http://en.wikipedia.org/wiki/Same_origin_policy

On Sat, Apr 2, 2011 at 8:09 AM, Morgaine <[email-masked]>wrote:

> You have a perfectly reasonable requirement for the service that you want
> to operate, and you need some means of meeting it.  I agree with that
> Perfect.  All you need then is an optional query in the protocol that
> allows a region to ask each asset service referenced by assets carried by
> newly arriving avatars the following question:
>
> PS. You need to note that when an asset service answers "Yes" to your
> query, this does not mean that it will necessarily honor its promise when
> you actually attempt to fetch items.  David's very important point about
>>> On Sat, Apr 2, 2011 at 4:55 AM, Morgaine <[email-masked]
>>> > wrote:
>>>
>>>> The specific trade-off that you are discussing is no different.  A
>>>> region that proxies all content has the "benefit" of acquiring control from
>>>> the asset servers over the items in the region, so that it can ensure that
>>>> everyone in the region not only obtains the items but obtains the *same
>>>> * items as everyone else.  That does indeed provide a greater guarantee
>>>> of consistency than a deployment in which the region only passes asset URIs
>>>> to clients who then fetch the items from asset services separately.  As
>>>> always though, it's a trade-off, since the proxied design has very poor
>>>> scalability compared to the distributed one.
>>>>
>>>> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca <[email-masked]
>>>> > wrote:
>>>>

---

From: Morgaine <[email-masked]>
Date: Sat, 2 Apr 2011 22:11:22 +0100

On Sat, Apr 2, 2011 at 9:37 PM, Dahlia Trimble <[email-masked]>wrote:

> I would hope a VWRAP protocol definition would include the possibility of
> regions proxying assets so such sandboxed clients can play a part in a VWRAP
> multiverse.

You'll be glad to hear Dahlia that VWRAP is being planned to include that
possibility. :-)

We have in VWRAP the concept of "deployment patterns" (David wrote a
document about them), which are architectural topologies and data flows
representing a range of common cases that have been identified as
important.  The architectures that we see today in SL and in Opensim are
among them, and not only for backwards compatibility ---  it is expected
that some providers will wish to continue to use them indefinitely.

As the VWRAP protocols are worked out, this set of documented deployment
patterns is intended to act as a requirements check on protocol structure
and options, so that we remain on track to meet all our requirements.

Of course, that is all theory at the moment, but the intention is there. :-)

That said, I think the exact case you describe is a good one to add
explicitly to the list of deployment patterns, rather than just hitching a
ride on the back of existing proxy architecture.

Morgaine.

==========================

On Sat, Apr 2, 2011 at 9:37 PM, Dahlia Trimble <[email-masked]>wrote:

>>>  So I want methods to prevent breaking my highly emergent world as much
>>> as possible.
>>>
>>
>>
>> Yes indeed!!!
>>
>> asset service answers "No" to you, then you can deny the incoming avatar
>> entry to your region, returning a status that indicates
>>
>> Most people will probably settle for "*best effort*" approaches, which
>> are quite likely to succeed.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>>
>> =====================
>>
>>
>>> I would like to argue that the region *should* get the capability to
>>> fetch all details. In other words, Prokofy would have to give up some
>>> control over the asset in case he allows it to be used by my region. Note
>>> that this does not mean that the region *has* to proxy the asset, just that
>>> in case the asset service refuses to serve a client it does not like, the
>>> region can insist on delivery  based on the capability it originally got. If
>>> that fails Proks asset service can not be called VWRAP compliant.
>>>
>>> If Prokofy does not want to relinquish  that level of control, fine, it
>>> is his right not to, but in that case the dresses should not be allowed to
>>> get into my region in the first place.  If people visit my region and find
>>> So, in summary, I very well see that there is no way to enforce
>>> consistent serving behaviour but it should at least be clear that it is
>>> non-standard and not conform the protocol. The way I am understanding you
>>> now, your argument seems to be just one step to far in the direction of
>>> anarchy.
>>> Or am i misreading you?
>>>
>>> --Vaughn
>>>
>>>
>>> (1) I just realise that the region might cheat and advertise its own
>>> asset brands claiming the competitions assets  could not be rendered... Oh
>>> well, one might hope that if there is enough choice in worlds such regions
>>> will be forced  out of business as well.
>>>
>>> On Sat, Apr 2, 2011 at 7:31 AM, Morgaine <[email-masked]
>>> > wrote:
>>>
>>>> Your client could be configured to attempt the item fetch at a known
>>>> good quality asset service *first* (perhaps one that you paid to use
>>>> because of its better service), automatically, and maybe even dynamically
>>>> depending on the type of item.
>>>>
>>>> On Sat, Apr 2, 2011 at 4:55 AM, Morgaine <
>>>> [email-masked]> wrote:
>>>>
>>>>> everyone in the region not only obtains the items but obtains the *
>>>>> same* items as everyone else.  That does indeed provide a greater
>>>>> guarantee of consistency than a deployment in which the region only passes
>>>>> asset URIs to clients who then fetch the items from asset services
>>>>> separately.  As always though, it's a trade-off, since the proxied design
>>>>> has very poor scalability compared to the distributed one.
>>>>>
>>>>> This can go some way towards overcoming the problem that you think
>>>>> might occur when assets are fetched by clients from asset services
>>>>> directly.  Although it won't help when the missing item is available from
>>>>> only a single asset service, it will help in many other cases, and it will
>>>>> compensate for service failures and network outages automatically at the
>>>>> same time.
>>>>>
>>>>> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca <
>>>>> [email-masked]> wrote:
>>>>>

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 3 Apr 2011 00:02:16 +0200

Morgain, all,

Ahha!, i was halfway my reply explaining that i was *not* asking for the
impossible, and did *not* want to impose my rules on others, but that i just
wanted to be able to know that stuff that i get into my region will be
visible to everybody present, and now i see that you got that. Good!
We are on the same page again :)

The way the draft relating tot the tourist model is now written i can
*never* be sure my visitors all get the same data, because i just juggle the
crude physics representation, and the viewers negotiate about anything else
with the asset service, fully out of my control.

You formulated a solution (requesting the transfer rights explicitly).
I was originally thinking of a solution where the protocol specifies that
the capability to get the crude physics representation of the asset in my
region would be *automatically* give me the right to download the full asset
(if I asked for that).  After reading your replies i now see that requesting
the transfer rights, just like like the viewers will do, is a better
solution. The same protocol messages could even be used, The region present
its credentials and either gets the capability or not.  The region can now
tells the agent service which of the assets agent service requested transfer
the avatar can bring. Its up to the viewer to deal with that information, it
might simply ignore it. In the latter case the avatar will be simulated by
the region without the offending asset. The asset service will subsequently
get requests from all viewers connected to the region for the assets in the
region. Some of those might not pass trust checks of the asset service. Bad
luck for the asset service, it has given a capability to the region and the
region will use that to get the asset. If the asset service has second
thoughts to often - causing download costs and lag, it will eventually end
up on the black list of the region service, and next time around the region
 might tell the agent service it can't allow asset Y from servivce X becasue
it does not trust assert service X.
It all sounds logical and transparent to me.

It also fits what meadhbh said:
>my recommendation has always been... "define mechanism, not policy."
As far as i can see that is what we do here.

Now, this brings me to a point of order. In september Kevin Tweedy made this
observation:

"<kevin.tweedy at xrgrid.com>
Date: Wed, 22 Sep 2010 13:40:15 -0400
May I suggest we stop arbitrarily trying to define things in emails and come
up with some kind of process into how to define what the first draft
specification should include?  Doesn’t W3C have a process on how this works?
 I think this is the fundamental problem of this group; we are mixing
vision, requirements, and design in the same email.  We are making design
decisions when we haven’t even defined the requirements."

I fully agree. We used to brainstorm in the group and assumed the editors of
the drafts would incorporate the generated ideas in new versions of the
draft.  At times that worked really well, at other times it did work not so
well. But currently we have no editors, so we need to do something new....

My question to the group is how do we consolidate this bit of discussion?

In general it seems to me we have managed to generate new enthusiasm in the
group, and we are on -or close to- the  point were we have enough critical
mass to continue. In my view we would really benefit from a true editor, and
it seems nobody is willing to take that responsibility yet. Can we really do
it collectively on the wiki? It would be a break with the way i think ietf
groups normally work, but i might be  kind off fitting for this highly
diverse group  :)

So will it work? What alternatives do we have?  comments please.

--Vaughn

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 3 Apr 2011 00:26:58 +0200

I wrote:
>The region can now tells the agent service which of the assets agent
service requested transfer the avatar can bring.

I meant to say:

The region can now tell the agent service which of the assets the agent
service requested transfer for, can actually be transfered.

(its late here...)

On Sun, Apr 3, 2011 at 12:02 AM, Vaughn Deluca <[email-masked]>wrote:

> Now, this brings me to a point of order. In september Kevin Tweedy made
> this observation:
>
> May I suggest we stop arbitrarily trying to define things in emails and
> come up with some kind of process into how to define what the first draft
> I fully agree. We used to brainstorm in the group and assumed the editors
> of the drafts would incorporate the generated ideas in new versions of the

---

From: Israel Alanis <[email-masked]>
Date: Sat, 2 Apr 2011 22:42:47 -0400

> when designing for scalability, the model to bear in mind is ...

Well, there are a lot of different models to keep in mind, and many different use cases. One particular use case to keep in mind is: "User acquires new outfit, and wants to 'show it off' in a highly populated region".

> Both worlds and asset services may include commercial, community, and personal services

Yes, yes and yes. I'm particularly concerned about how the model affects the ability to host personal asset services.

> a proxying region, which would get slammed for every asset worn by every avatar present.

Granted the collection of services that are provided by the region need to be scaled to meet the demands of that region. That's all part of capacity planning.

> regions run many different CPU-intensive tasks, including physics simulation and server-side scripting, and absolutely cannot afford to serve assets too 

Well... who said the same CPU's have to do proxying, physics simulation and server-side scripting? Asset proxying is a different service than physics simulation and can be on separate hardware, could make use of geographically distributed caching, and in certain deployment patterns, the same caching services could be shared by different regions. (Server-side scripting is a discussion for another day).

> This is why we have to go parallel...

Totally agree, and a proxying model could and should also take advantage of parallelism.

> I think you're wrong that it has to cost much money. 
?vs?
> It costs money to host a high performance and scalable asset service and a high bandwidth network to handle the traffic.  A lot of money. 

I think what you're saying is: "It costs a lot of money to build a scalable asset service, but if assets are spread throughout the internet they don't have to be scalable." But that's not quite right. You're opening up every asset server to the VW equivalent of being slashdotted, so are you sure you're not forcing *every* asset service to be scalable and handle a lot of bandwith and network traffic? It's the exact opposite of your intention, but I think that's the result, all the same.

This particular design decision has a big effect on the economics of the VW infrastructure. I'd rather the economics to work out such that a region provider who wishes to build a region that supports a small population, can do so economically. A region that wants to host a *large* population has to bear that cost of providing that scalable asset service. 

I want the economics of hosting a small asset service to be a non-issue (as to best promote creation and creativity). Creating a high bar to provide asset services will mean that service will cost money and people shouldn't have to pay money just to create or own VW objects (I'm using 'own' here to refer to maintaining their existence, I'm not trying to make a 'leftist'/'communist' statement about ownership ;)

- Izzy

On Apr 2, 2011, at 3:58 PM, Morgaine wrote:

> Izzy, when designing for scalability, the model to bear in mind is that of seasoned virtual world travelers whose inventories contain assets from many different worlds, those assets being served by many different asset services.  Both worlds and asset services may include commercial, community, and personal services, and as the metaverse grows, that set is highly likely to become progressively less clustered and more diverse.
> 
> When those seasoned travelers click on an advertised VW link and perform an inter-world teleport to one particular world's region to share an experience, their "worn" assets (the only ones of interest to the region) will contain references to asset services spread widely across the Internet.  The fetches by the travelers' clients occur over many parallel paths from clients to asset services, so one can reasonably expect reduced network contention and reduced asset server loading because they are both spread out over however many asset services are being referenced by the overall set of assets in the region.
> 
> This is very different to the case of a proxying region, which would get slammed for every asset worn by every avatar present.  In our current architecture, regions run many different CPU-intensive tasks, including physics simulation and server-side scripting, and absolutely cannot afford to serve assets too unless your scalability requirements are very low indeed, ie. just a few dozen avatars of today's kind.  We've hit the ceiling already on region scalability done that way.  There is nowhere to go in that direction at all beyond improving the code like Intel demonstrated, and that work is subject to a law of diminishing returns.
> 
> This is why we have to go parallel, and I think you're wrong that it has to cost much money.  As we spread the load across more and more asset services, we are simply better utilizing all the hardware that's already out there on the Internet, at least in respect of community and private resources.  But add to the community and private resources the commercial asset services that are likely to appear to exploit this opportunity, and not only will the number of asset services leap, but the power of each one will rocket too, because, after all, these businesses will be heavily optimized for the job.
> 
> As to why a world would want clients to access external asset services instead of providing its own implementation, that's an easy question.  It costs money to host a high performance and scalable asset service and a high bandwidth network to handle the traffic.  A lot of money.  In contrast, it costs a world nothing to let others serve the assets to clients.  And that matters to the bottom line.
> 
> 
> Morgaine.
> 
> 
> 
> 
> ======================
>

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 02 Apr 2011 20:22:38 -0700

Somehow I feel the basic asset server being able to login and download 
assets is now priority, yet I also wondered the best way to patch this 
into the current mode of viewers.

Maybe offer (1) by proxy (sim-side) and (2) by patch (viewer-side) that 
either of these two are optional and neither are mandatory for now. 
Thoughts?

Israel Alanis wrote:
> Well, there are a lot of different models to keep in mind, and many 
> different use cases. One particular use case to keep in mind is: "User 
> acquires new outfit, and wants to 'show it off' in a highly populated 
> region".
>
> Yes, yes and yes. I'm particularly concerned about how the model 
> affects the ability to host personal asset services.
>
> Granted the collection of services that are provided by the region 
> need to be scaled to meet the demands of that region. That's all part 
> of capacity planning.
>
> > regions run many different CPU-intensive tasks, including physics 
> simulation and server-side scripting, and absolutely cannot afford to 
> serve assets too 
>
> Well... who said the same CPU's have to do proxying, physics 
> simulation and server-side scripting? Asset proxying is a different 
> service than physics simulation and can be on separate hardware, could 
> make use of geographically distributed caching, and in certain 
> deployment patterns, the same caching services could be shared by 
> different regions. (Server-side scripting is a discussion for another 
> day).
>
> > It costs money to host a high performance and scalable asset service 
> and a high bandwidth network to handle the traffic.  A *lot* of money. 
>
> I think what you're saying is: "It costs a lot of money to build a 
> scalable asset service, but if assets are spread throughout the 
> internet they don't have to be scalable." But that's not quite right. 
> You're opening up every asset server to the VW equivalent of being 
> slashdotted, so are you sure you're not forcing *every* asset service 
> to be scalable and handle a lot of bandwith and network traffic? It's 
> the exact opposite of your intention, but I think that's the result, 
> all the same.
>
> This particular design decision has a big effect on the economics of 
> the VW infrastructure. I'd rather the economics to work out such that 
> a region provider who wishes to build a region that supports a small 
> population, can do so economically. A region that wants to host a 
> *large* population has to bear that cost of providing that scalable 
> asset service. 
>
> I want the economics of hosting a small asset service to be a 
> non-issue (as to best promote creation and creativity). Creating a 
> high bar to provide asset services will mean that service will cost 
> money and people shouldn't have to pay money just to create or own VW 
> objects (I'm using 'own' here to refer to maintaining their existence, 
> I'm not trying to make a 'leftist'/'communist' statement about 
> ownership ;)
>
> - Izzy
>
>
>> Izzy, when designing for scalability, the model to bear in mind is 
>> that of seasoned virtual world travelers whose inventories contain 
>> assets from many different worlds, those assets being served by many 
>> different asset services.  Both worlds and asset services may include 
>> commercial, community, and personal services, and as the metaverse 
>> grows, that set is highly likely to become progressively less 
>> clustered and more diverse.
>>
>> When those seasoned travelers click on an advertised VW link and 
>> perform an inter-world teleport to one particular world's region to 
>> share an experience, their "worn" assets (the only ones of interest 
>> to the region) will contain references to asset services spread 
>> widely across the Internet.  The fetches by the travelers' clients 
>> occur over many parallel paths from clients to asset services, so one 
>> can reasonably expect reduced network contention and reduced asset 
>> server loading because they are both spread out over however many 
>> asset services are being referenced by the overall set of assets in 
>> the region.
>>
>> This is very different to the case of a proxying region, which would 
>> get slammed for every asset worn by every avatar present.  In our 
>> current architecture, regions run many different CPU-intensive tasks, 
>> including physics simulation and server-side scripting, and 
>> absolutely cannot afford to serve assets too unless your scalability 
>> requirements are very low indeed, ie. just a few dozen avatars of 
>> today's kind.  We've hit the ceiling already on region scalability 
>> done that way.  There is nowhere to go in that direction at all 
>> beyond improving the code like Intel demonstrated, and that work is 
>> subject to a law of diminishing returns.
>>
>> This is why we have to go parallel, and I think you're wrong that it 
>> has to cost much money.  As we spread the load across more and more 
>> asset services, we are simply better utilizing all the hardware 
>> that's already out there on the Internet, at least in respect of 
>> community and private resources.  But add to the community and 
>> private resources the commercial asset services that are likely to 
>> appear to exploit this opportunity, and not only will the number of 
>> asset services leap, but the power of each one will rocket too, 
>> As to why a world would want clients to access external asset 
>> services instead of providing its own implementation, that's an easy 
>> question.  It costs money to host a high performance and scalable 
>> asset service and a high bandwidth network to handle the traffic.  A 
>> *lot* of money.  In contrast, it costs a world nothing to let others 
>> serve the assets to clients.  And that matters to the bottom line.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>> ======================
>>
>> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     > As always though, it's a trade-off, since the proxied design
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>     we use in
>>     .  It is
>>     > On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca
>>     <[email-masked] <mailto:[email-masked]>>
>>     > wrote:
>>     >>
>>     >>           In such a model, the client is responsible for
>>     fetching the
>>     >> additional
>>     >>           information needed to render the item's visual
>>     presence from a
>>     >> separate
>>     >>           service.  This fetch can be done *under the
>>     credentials of the
>>     >> end user*

--

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 02 Apr 2011 20:51:29 -0700

Some stated the proxy-to-asset-server is built into the sim; however, 
keep in mind possible legacy support where the asset server may proxy 
the simulator.

Dzonatas Sol wrote:
> Maybe offer (1) by proxy (sim-side) and (2) by patch (viewer-side) 
> that either of these two are optional and neither are mandatory for 
> now. Thoughts?
>
> Israel Alanis wrote:
>>
>> different use cases. One particular use case to keep in mind is: 
>> "User acquires new outfit, and wants to 'show it off' in a highly 
>> populated region".
>>
>> service than physics simulation and can be on separate hardware, 
>> could make use of geographically distributed caching, and in certain 
>> > I think you're wrong that it has to cost much money. ?vs?
>> > It costs money to host a high performance and scalable asset 
>> service and a high bandwidth network to handle the traffic.  A *lot* 
>> of money.
>> objects (I'm using 'own' here to refer to maintaining their 
>> existence, I'm not trying to make a 'leftist'/'communist' statement 
>> about ownership ;)
>>
>> - Izzy
>>
>>
>>> different asset services.  Both worlds and asset services may 
>>> include commercial, community, and personal services, and as the 
>>> metaverse grows, that set is highly likely to become progressively 
>>> less clustered and more diverse.
>>>
>>> occur over many parallel paths from clients to asset services, so 
>>> one can reasonably expect reduced network contention and reduced 
>>> asset server loading because they are both spread out over however 
>>> many asset services are being referenced by the overall set of 
>>> assets in the region.
>>>
>>> current architecture, regions run many different CPU-intensive 
>>> tasks, including physics simulation and server-side scripting, and 
>>>     >>           simulation. [...] The other end of the delivery 
>>> spectrum
>>>     >> involves passing

--

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 3 Apr 2011 08:56:15 +0200

Hi Dzonatas

Can you expand on that, what would be needed for legacy support in VWAP
terms ?,
If i want to read up on how the asset server may proxy the simulator, what
would you recommend me to read?

-- Vaughn

On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol <[email-masked]> wrote:

> Some stated the proxy-to-asset-server is built into the sim; however, keep
> in mind possible legacy support where the asset server may proxy the
> simulator.
>
>
> Dzonatas Sol wrote:
>
>> assets is now priority, yet I also wondered the best way to patch this into
>> the current mode of viewers.
>>
>>> Yes, yes and yes. I'm particularly concerned about how the model affects
>>> the ability to host personal asset services.
>>>
>>> Granted the collection of services that are provided by the region need
>>> to be scaled to meet the demands of that region. That's all part of capacity
>>> planning.
>>>
>>> simulation and server-side scripting, and absolutely cannot afford to serve
>>> assets too
>>> Well... who said the same CPU's have to do proxying, physics simulation
>>> and server-side scripting? Asset proxying is a different service than
>>> physics simulation and can be on separate hardware, could make use of
>>> geographically distributed caching, and in certain deployment patterns, the
>>> same caching services could be shared by different regions. (Server-side
>>> scripting is a discussion for another day).
>>>
>>> scalable asset service, but if assets are spread throughout the internet
>>> they don't have to be scalable." But that's not quite right. You're opening
>>> up every asset server to the VW equivalent of being slashdotted, so are you
>>> sure you're not forcing *every* asset service to be scalable and handle a
>>> lot of bandwith and network traffic? It's the exact opposite of your
>>> intention, but I think that's the result, all the same.
>>>
>>> This particular design decision has a big effect on the economics of the
>>> VW infrastructure. I'd rather the economics to work out such that a region
>>> provider who wishes to build a region that supports a small population, can
>>> do so economically. A region that wants to host a *large* population has to
>>> bear that cost of providing that scalable asset service.
>>> I want the economics of hosting a small asset service to be a non-issue
>>> (as to best promote creation and creativity). Creating a high bar to provide
>>> asset services will mean that service will cost money and people shouldn't
>>> have to pay money just to create or own VW objects (I'm using 'own' here to
>>> refer to maintaining their existence, I'm not trying to make a
>>> 'leftist'/'communist' statement about ownership ;)
>>>
>>> - Izzy
>>>
>>>
>>>  Izzy, when designing for scalability, the model to bear in mind is that
>>>> of seasoned virtual world travelers whose inventories contain assets from
>>>> many different worlds, those assets being served by many different asset
>>>> When those seasoned travelers click on an advertised VW link and perform
>>>> an inter-world teleport to one particular world's region to share an
>>>> will contain references to asset services spread widely across the Internet.
>>>>  The fetches by the travelers' clients occur over many parallel paths from
>>>> clients to asset services, so one can reasonably expect reduced network
>>>> contention and reduced asset server loading because they are both spread out
>>>> over however many asset services are being referenced by the overall set of
>>>> assets in the region.
>>>>
>>>> This is why we have to go parallel, and I think you're wrong that it has
>>>> to cost much money.  As we spread the load across more and more asset
>>>> services, we are simply better utilizing all the hardware that's already out
>>>> there on the Internet, at least in respect of community and private
>>>> resources.  But add to the community and private resources the commercial
>>>> asset services that are likely to appear to exploit this opportunity, and
>>>> not only will the number of asset services leap, but the power of each one
>>>> will rocket too, because, after all, these businesses will be heavily
>>>> optimized for the job.
>>>>
>>>> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis <[email-masked]<mailto:
>>>> [email-masked]>> wrote:
>>>>

---

From: Morgaine <[email-masked]>
Date: Sun, 3 Apr 2011 11:07:19 +0100

Great to hear that we're on the same page, Vaughn!

The detail is probably a bit different to how you described it, because
region and agent policy scopes are separate, ie. the agent service doesn't
have a role in determining region policy, it just provides an agent.  Since
asset services are entirely concerned with region functions alone, this puts
them out of scope for the agent service, at least according to the last set
of list discussions we had on the topic.

I expect it's the client that you need to consult for its current list of
asset services, because it keeps tally as it encounters new ones in its
travels.  The agent service only supplies a seed cap to kick things off with
an initial asset service and inventory to hold the default avatar.  This is
legacy stuff though, dating back from when there was a single centralized
asset store.  It needs reworking now that we've gone beyond that singleton..

This whole area of protocol design was never finalized because the Lab
withdrew while we were still discussing how the OGP model was going to
support VW interop.  The OGP-based drafts became totally out of date as soon
as the requirements for interop materialized, and we haven't recovered from
that yet.

I agree with your call which echoed Kevin's earlier one, that we need to get
on with this!  However, it doesn't start with a doc, but with an agreed
design concept, so that the first doc is roughly in the right area!

This is a partial list of the requirements which I think need to be met:

   - Handle a dynamic set of asset services, one being the minimum (and only
   usable in a walled garden), while the maximum is unlimited.
   - Never to disallow an agent from using its current agent credentials to
   travel to another world (agent registration must not be confused with world
   policy).
   - Let asset services determine asset distribution policy, and provide the
   means for regions to query that policy (your consistency requirement).
   - Decide where the user state is held.  If it's in the agent service then
   the agent service must be agnostic to worlds and accept all travel
   requests.  If we cannot agree to make the agent service VW agnostic, then
   state will have to be held in the client.

Once we have a rough model of that in our minds, then we can:

   - Run through a few iterations of basic top-level pseudocode showing how
   the agent service, asset services and clients handle the above split of
   responsibilities.
   - Write the first draft document reflecting the above.
   - Rinse and repeat.

Morgaine.

=======================

On Sat, Apr 2, 2011 at 11:26 PM, Vaughn Deluca <[email-masked]>wrote:

>> In general it seems to me we have managed to generate new enthusiasm in
>> the group, and we are on -or close to- the  point were we have enough
>> critical mass to continue. In my view we would really benefit from a true
>> editor, and it seems nobody is willing to take that responsibility yet. Can
>> we really do it collectively on the wiki? It would be a break with the way i
>> think ietf groups normally work, but i might be  kind off fitting for this
>> highly diverse group  :)
>>
>>>> fetch all details. [...]  Note that this does not mean that the region *has*
>>>> to proxy the asset, just that in case the asset service refuses to serve a
>>>> I was arguing from the perspecive of a region service without making
>>>> that explicit. Note i was *not* advocating the region proxies everything,
>>>> just that it lives up to its promises about object presence. Also note that
>>>> i do  *not* always have the option to pick another high quality asset
>>>> service, since I normally do not own the assets. I will use Prokofy as an
>>>> example just for the fun of it.  He is highly worried about content theft,
>>>> so (in the unlikely case he wants to start selling stuff outside of SL) he
>>>> might use this deployment pattern.  Assume he sells wonderful sexy dresses
>>>> to two customers, that can only be fetched from his own asset service for
>>>> My proposal would be that the whatever the region gets MUST be
>>>> guaranteed by protocol to be delivered to  anybody within the region
>>>> requesting it. If the asset service does not want to serve a cryptocomunist
>>>> copyleftist, fine, but IF it has given the region a capability, it MUST
>>>> serve the full asset to be VWRAP compliant. Its *my* choice as a region
>>>> deployer to download the full asset to be able to guarantee region
>>>> consistency if I want to. I will try to avoid that as much as possible, but
>>>> if my customers complain, i will be forces to start doing this for certain
>>>> asset services that i know show discriminatory behaviour against for
>>>> instance copyleftist.
>>>>
>>>> On Sat, Apr 2, 2011 at 7:31 AM, Morgaine <
>>>>>> Every design choice results in a trade-off, Vaughn, improving one
>>>>>> thing at the expense of something else.  If every time we offered a service
>>>>>> we had to inform its users about the downsides of all the trade-offs we have
>>>>>> made, they would have an awful lot to read. ;-)
>>>>>>
>>>>>> in VWRAP a form of asset addressing that provides massive scalability at the
>>>>>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .
>>>>>> It is based on the concept of the URI containing a host part and a hash
>>>>>> part, where the hash is generated (once, at the time of storage to the asset
>>>>>> PS. This design for hash-based asset addressing is already being
>>>>>> tested by Mojito Sorbet in her experimental world and client.  It would give

---

From: Morgaine <[email-masked]>
Date: Sun, 3 Apr 2011 12:01:35 +0100

On Sun, Apr 3, 2011 at 3:42 AM, Israel Alanis <[email-masked]> wrote:

>
> I think what you're saying is: "It costs a lot of money to build a scalable
> asset service, but if assets are spread throughout the internet they don't
> have to be scalable." But that's not quite right. You're opening up every
> asset server to the VW equivalent of being slashdotted, so are you sure
> you're not forcing *every* asset service to be scalable and handle a lot of
> bandwith and network traffic? It's the exact opposite of your intention, but
> I think that's the result, all the same.
>
>

We actually discussed this in the early days of the list, and I was
advocating that part of the duties of a huge commercial service that
supports VW interop needs to be to temporarily cache assets of new arrivals
from other worlds, as an independent service of the large VW, ie. a Caching
Service.

The reason why I believe a separate Caching Service (unrelated to any Asset
Service) is needed is because the commercial service will not be able to
maintain a desired quality of service without it for its users.

Imagine a Truly Awesome Commercial World, able to support media crowd events
of 100,000 avatars.  Lucy The Musical Furries Fan runs a tiny world for her
family with its own midget integrated asset service, and hears that her
adored Musical Furries are going to play at Truly Awesome Commercial World,
so off she teleports to the venue.  Instantly on arrival, 100,000 fans of
the Musical Furries slashdot her asset service into a smoldering slag heap
as they all try to fetch her avatar's assets.

Clearly this is not going to work.  Quite apart from Lucy's problem, it is
the Truly Awesome Commercial World that suffers most, because it now has
100,000 fans who are faced with a broken simulation.  It's no longer very
awesome.

(Not allowing entry to Lucy is not an option because the huge world relies
on 100,000 people like Lucy arriving to support the event, many of whom are
in Lucy's situation.)

Unfortunately I never managed to get anyone interested in the concept of a
Caching Service as an independent entity.  Perhaps it's time to revive the
idea.

Note that the Caching Service would be yet another independent service,
conceptually external and not related administratively with any other entity
in our picture.  It would be optionally engaged by a region that wants to
open its doors to the metaverse but takes pride in offering a better quality
of service than its visitors' asset services can provide by themselves.

Morgaine.

============================

On Sun, Apr 3, 2011 at 3:42 AM, Israel Alanis <[email-masked]> wrote:

> Granted the collection of services that are provided by the region need to
> be scaled to meet the demands of that region. That's all part of capacity
> planning.
>
> Well... who said the same CPU's have to do proxying, physics simulation and
> server-side scripting? Asset proxying is a different service than physics
> simulation and can be on separate hardware, could make use of geographically
> distributed caching, and in certain deployment patterns, the same caching
> services could be shared by different regions. (Server-side scripting is a
> discussion for another day).
>
> > It costs money to host a high performance and scalable asset service and
> a high bandwidth network to handle the traffic.  A *lot* of money.
>
> I think what you're saying is: "It costs a lot of money to build a scalable
> asset service, but if assets are spread throughout the internet they don't
> have to be scalable." But that's not quite right. You're opening up every
> asset server to the VW equivalent of being slashdotted, so are you sure
> you're not forcing *every* asset service to be scalable and handle a lot of
> bandwith and network traffic? It's the exact opposite of your intention, but
> I think that's the result, all the same.
>
> This particular design decision has a big effect on the economics of the VW
> infrastructure. I'd rather the economics to work out such that a region
> I want the economics of hosting a small asset service to be a non-issue (as
> to best promote creation and creativity). Creating a high bar to provide
> bandwidth network to handle the traffic.  A *lot* of money.  In contrast,
> it costs a world nothing to let others serve the assets to clients.  And
> that matters to the bottom line.
>
>
> Morgaine.
>
>
>
>
> ======================
>
>> region
>> >>           information needed to render the item's visual presence from
>> a
>> >> separate
>> >>           service.  This fetch can be done *under the credentials of
>> the
>> >> end user*

---

From: Morgaine <[email-masked]>
Date: Sun, 3 Apr 2011 12:38:58 +0100

I should mention that a Caching Service doesn't have to be a transparent
cache working behind the scenes within the region.  That kind of cache can
always be introduced without our protocol needing to know about it, and such
caches are in use by regions already I believe.

Instead, it could be a negotiated facility for which the client can query
the region to see if it exists, and if it exists then the client has the
choice of using it or not, and the negotiation might also allow a different
Caching Service to be nominated.

(Lucy might work for IBM which runs an IBM Employee Caching Service using
5,000 Blue Gene machines as a perk for employees so that they always render
instantly on any world they visit, giving IBM a good name worldwide ... :P
So of course Lucy would want to tell the region to use her employer's
Caching Service.)

Also, a world might not necessarily be interested in maintaining a high
quality of service, but very interested in revenue instead, and so
requesting use of its Caching Service could be an extra-cost option at
entry.  Who knows.  Maybe attending the Musical Furries gig is free, while
paying for the Caching Service is the cost of admission. Nobody really knows
where this is leading. :-)

This is just one possibility out of many possible variations on the theme.
Even if the Caching Service is hidden within the region and is totally
transparent to the protocol, it still offers us the means to embrace VW
interop while maintaining a high quality of service as region populations
grow, and that's important.

Morgaine.

======================

On Sun, Apr 3, 2011 at 12:01 PM, Morgaine <[email-masked]>wrote:

> On Sun, Apr 3, 2011 at 3:42 AM, Israel Alanis <[email-masked]>wrote:
>
>>
> Imagine a Truly Awesome Commercial World, able to support media crowd
> events of 100,000 avatars.  Lucy The Musical Furries Fan runs a tiny world
> for her family with its own midget integrated asset service, and hears that
> her adored Musical Furries are going to play at Truly Awesome Commercial
> World, so off she teleports to the venue.  Instantly on arrival, 100,000
> fans of the Musical Furries slashdot her asset service into a smoldering
> slag heap as they all try to fetch her avatar's assets.
>
> On Sun, Apr 3, 2011 at 3:42 AM, Israel Alanis <[email-masked]>wrote:
>
>>
>>> might

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 3 Apr 2011 14:24:34 +0200

Morgaine,

I will put my comments inline for clarity

>The detail is probably a bit different to how you described it,
>because region and agent policy scopes are separate, ie. the
>agent service doesn't have a role in determining region policy, it
>just provides an agent.

Hmmm, i certainly did not want to imply that the agent service was
determining region policy! All I tried to say was that the agent service
requests to place an agent in the region, and informs the region about the
assets it wants to bring.

>Since asset services are entirely concerned with region functions alone,
>this puts them out of scope for the agent service, at least according to
>the last set of list discussions we had on the topic.

I might have gotten this wrong but in my view the the Agent service handles
the all things related to the agent, and that would  surely include the
*references* to attachments like dresses?   If the user wants to visit some
region, she  asks her agent service to place the avatar in that region?

>I expect it's the client that you need to consult for its current list of
asset services,
> because it keeps tally as it encounters new ones in its travels.

Hmm, no, that is not what i had in  mind... I expect the agent service keeps
track of the assets currently in use by the agent, i.e. a list of references
to data in asset services.

>The agent service only supplies a seed cap to kick things off with an
initial
>asset service and inventory to hold the default avatar.  This is legacy
stuff
>though, dating back from when there was >a single centralized asset store.
> It needs reworking now that we've gone beyond that singleton..

We badly need some diagrams to illustrate our thinking. Is there anywhere
something that depicts the high level flow of requests and responses?

>This whole area of protocol design was never finalized because the Lab
withdrew
>while we were still discussing how the OGP model was going to support VW
interop.
> The OGP-based drafts became totally >out of date as soon as the
requirements for
>interop materialized, and we haven't recovered from that yet.

>I agree with your call which echoed Kevin's earlier one, that we need to
get on with this!  >However, it doesn't start with a doc, but with an agreed
design concept, so that the first doc is >roughly in the right area!

It depends on your definition of a doc, even your list below could be a doc
if placed on the vwrap wiki.   :)

>Handle a dynamic set of asset services, one being the minimum
> (and only usable in a walled garden), while the maximum is unlimited.

OK

>Never to disallow an agent from using its current agent credentials to
travel to
>another world  (agent registration must not be confused with world policy).

I do not get this. This is surely the choice of the agent service? If some
agent service wants to prevent its agents to connect to some region fine,
that their policy!  And if i, as a user  don't like that, i go and get me a
service that fits my needs better. In the end i could use my own agent
service running as part of my own client? I am assuming that there will be
some mechanism to use an external identity provider if needed.

>Let asset services determine asset distribution policy, and provide the
means for
> regions to query that policy (your consistency requirement).

OK

>Decide where the user state is held.  If it's in the agent service then the
agent
>service must be agnostic to worlds and accept all travel requests.

For sure the user state should be held by the agent service, that's what its
designed for (i think?) and no, you can't control the agent's  service
policy! That fully and completely up to that service. The only requirement
is that the service handles the defined protocol messages, but refusing to
send a user to a certain world could be a key requirement for some services.
I am not at all in favour of this, but i am sure some people are; think of a
kids world, were you might want to prevent visits to the big bad virtual
universe rife with sex, drugs and rock and roll.

>If we cannot agree to make the agent service VW agnostic, then state will
>have to be held in the client.

Maybe i am naive, but my feeling is that *if* you would hold the agent state
in the client, that would be nothing else than integrating an agent service
in the client? Or am i totally missing your meaning here?

>Run through a few iterations of basic top-level pseudocode showing how the
agent
>service, asset services and clients handle the above split of
responsibilities.
>Write the first draft document reflecting the above.
>Rinse and repeat.

Yes!

--Vaughn

On Sun, Apr 3, 2011 at 12:07 PM, Morgaine <[email-masked]>wrote:

> I agree with your call which echoed Kevin's earlier one, that we need to
> get on with this!  However, it doesn't start with a doc, but with an agreed
>    - Handle a dynamic set of asset services, one being the minimum (and
>    only usable in a walled garden), while the maximum is unlimited.
>    - Never to disallow an agent from using its current agent credentials
>    to travel to another world (agent registration must not be confused with
>    world policy).
>    - Let asset services determine asset distribution policy, and provide
>    the means for regions to query that policy (your consistency requirement).
>    - Decide where the user state is held.  If it's in the agent service
>    then the agent service must be agnostic to worlds and accept all travel
>    - Run through a few iterations of basic top-level pseudocode showing
>    how the agent service, asset services and clients handle the above split of
>    responsibilities.
>>> On Sat, Apr 2, 2011 at 5:09 PM, Morgaine <[email-masked]
>>> > wrote:
>>>
>>>> On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca <[email-masked]
>>>> > wrote:
>>>>
>>>> You have a perfectly reasonable requirement for the service that you
>>>> want to operate, and you need some means of meeting it.  I agree with that
>>>> On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca <[email-masked]
>>>> > wrote:
>>>>
>>>>> Morgaine, Meadhbh,
>>>>>
>>>>>> The scheme has a long list of benefits, and overcoming (to some
>>>>>> extent) poor quality asset services is just one of them.
>>>>>>
>>>>>>
>>>>>> Morgaine.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ===================
>>>>>>
>>>>>>
>>>>>>> If we're going to warn users of the potential for inconsistency in
>>>>>>> the distributed deployment as you suggest, are we also going to warn them of
>>>>>>> You mentioned users "voting with their feet" or choosing to accept
>>>>>>> the risk of inconsistency.  Well that will happen anyway, when services fail
>>>>>>> and users get annoyed.  If some asset services refuse to send the requested
>>>>>>>> the end user*

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 03 Apr 2011 10:20:31 -0700

Probably easy as suggested in other terms here on this list, as how the 
client contacts the asset services now in the regions. The newer issue 
is to unitize that asset services. Since their is proprietary (legacy) 
code then we can't expect that to change, and some form of proxy is of 
need. Whatever works best, I tried to narrow it down to suggestions here.

Eventually, the agent domain is ideal to handle the direction of the 
asset services. This concept, unfortunately, ended support awhile ago 
with changes in LL.
Also see; http://wiki.secondlife.com/wiki/Agent_Domain
And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset (warn: 
unstructured collaborative notes, dumped on me and I tried to fix)

I tried to find previous visuals.

I'd imagine the agent domain could grow out of unitized versions of 
asset services. Despite that, I think that concept helps view where we 
were at in discussion and what didn't happen.

Vaughn Deluca wrote:
> Hi�Dzonatas
>
> Can you expand on that, what would be needed for legacy support in 
> VWAP terms�?,
> If i want to read up on how the�asset server may proxy the simulator, 
> what would you recommend me to read?
>
> -- Vaughn
>
> On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol <[email-masked] 
>     Some stated the proxy-to-asset-server is built into the sim;
>     however, keep in mind possible legacy support where the asset
>     server may proxy the simulator.
>
>
>     Dzonatas Sol wrote:
>
>         Somehow I feel the basic asset server being able to login and
>         download assets is now priority, yet I also wondered the best
>         way to patch this into the current mode of viewers.
>
>         Maybe offer (1) by proxy (sim-side) and (2) by patch
>         (viewer-side) that either of these two are optional and
>         neither are mandatory for now. Thoughts?
>
>         Israel Alanis wrote:
>
>
>             Well, there are a lot of different models to keep in mind,
>             and many different use cases. One particular use case to
>             keep in mind is: "User acquires new outfit, and wants to
>             'show it off' in a highly populated region".
>
>             Yes, yes and yes. I'm particularly concerned about how the
>             model affects the ability to host personal asset services.
>
>             Granted the collection of services that are provided by
>             the region need to be scaled to meet the demands of that
>             region. That's all part of capacity planning.
>
>             > regions run many different CPU-intensive tasks,
>             including physics simulation and server-side scripting,
>             and absolutely cannot afford to serve assets too
>             Well... who said the same CPU's have to do proxying,
>             physics simulation and server-side scripting? Asset
>             proxying is a different service than physics simulation
>             and can be on separate hardware, could make use of
>             geographically distributed caching, and in certain
>             deployment patterns, the same caching services could be
>             shared by different regions. (Server-side scripting is a
>             > It costs money to host a high performance and scalable
>             asset service and a high bandwidth network to handle the
>             traffic. �A *lot* of money.
>             I think what you're saying is: "It costs a lot of money to
>             build a scalable asset service, but if assets are spread
>             throughout the internet they don't have to be scalable."
>             But that's not quite right. You're opening up every asset
>             server to the VW equivalent of being slashdotted, so are
>             you sure you're not forcing *every* asset service to be
>             scalable and handle a lot of bandwith and network traffic?
>             It's the exact opposite of your intention, but I think
>             that's the result, all the same.
>
>             This particular design decision has a big effect on the
>             economics of the VW infrastructure. I'd rather the
>             economics to work out such that a region provider who
>             wishes to build a region that supports a small population,
>             can do so economically. A region that wants to host a
>             *large* population has to bear that cost of providing that
>             scalable asset service.
>             I want the economics of hosting a small asset service to
>             be a non-issue (as to best promote creation and
>             creativity). Creating a high bar to provide asset services
>             will mean that service will cost money and people
>             shouldn't have to pay money just to create or own VW
>             objects (I'm using 'own' here to refer to maintaining
>             their existence, I'm not trying to make a
>                 Izzy, when designing for scalability, the model to
>                 bear in mind is that of seasoned virtual world
>                 travelers whose inventories contain assets from many
>                 different worlds, those assets being served by many
>                 different asset services. �Both worlds and asset
>                 services may include commercial, community, and
>                 personal services, and as the metaverse grows, that
>                 set is highly likely to become progressively less
>                 When those seasoned travelers click on an advertised
>                 VW link and perform an inter-world teleport to one
>                 particular world's region to share an experience,
>                 their "worn" assets (the only ones of interest to the
>                 region) will contain references to asset services
>                 spread widely across the Internet. �The fetches by the
>                 travelers' clients occur over many parallel paths from
>                 clients to asset services, so one can reasonably
>                 expect reduced network contention and reduced asset
>                 server loading because they are both spread out over
>                 however many asset services are being referenced by
>                 the overall set of assets in the region.
>
>                 This is very different to the case of a proxying
>                 region, which would get slammed for every asset worn
>                 by every avatar present. �In our current architecture,
>                 regions run many different CPU-intensive tasks,
>                 including physics simulation and server-side
>                 scripting, and absolutely cannot afford to serve
>                 assets too unless your scalability requirements are
>                 very low indeed, ie. just a few dozen avatars of
>                 today's kind. �We've hit the ceiling already on region
>                 scalability done that way. �There is nowhere to go in
>                 that direction at all beyond improving the code like
>                 Intel demonstrated, and that work is subject to a law
>                 of diminishing returns.
>
>                 This is why we have to go parallel, and I think you're
>                 wrong that it has to cost much money. �As we spread
>                 the load across more and more asset services, we are
>                 simply better utilizing all the hardware that's
>                 already out there on the Internet, at least in respect
>                 of community and private resources. �But add to the
>                 community and private resources the commercial asset
>                 services that are likely to appear to exploit this
>                 opportunity, and not only will the number of asset
>                 services leap, but the power of each one will rocket
>                 too, because, after all, these businesses will be
>                 heavily optimized for the job.
>
>                 As to why a world would want clients to access
>                 external asset services instead of providing its own
>                 implementation, that's an easy question. �It costs
>                 money to host a high performance and scalable asset
>                 service and a high bandwidth network to handle the
>                 traffic. �A *lot* of money. �In contrast, it costs a
>                 world nothing to let others serve the assets to
>                 clients. �And that matters to the bottom line.
>
>
>                 Morgaine.
>
>
>
>
>                 ======================
>
>                 On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis
>                 <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked]
>                 <mailto:[email-masked]>>> wrote:
>
>                 � �> As always though, it's a trade-off, since the
>                 proxied design
>                 � �has very poor scalability compared to the
>                 distributed one.
>
>                 � �I don't agree with that... If a user enters a
>                 highly populated
>                 � �region,
>                 � �every other client is going to (could and should be
>                 trying to)
>                 � �hit the
>                 � �asset server(s) for the assets that the user is
>                 wearing (assuming
>                 � �they're not cached locally). �Every asset server
>                 has to be scaled up
>                 � �to the point that it can handle that load from all
>                 over...
>
>                 � �If I'm hosting a region that supports 10s of
>                 thousands of
>                 � �simultaneous
>                 � �users (thinking of the future), I already have to
>                 scale to meet that
>                 � �demand. If the region is proxying the assets, then,
>                 yes the
>                 � �region has
>                 � �to be scaled to meet that asset demand too, but it
>                 already has to be
>                 � �scaled to meet other demands of being a region
>                 server... and why is
>                 � �scaling those asset proxy services hard? �It's
>                 going to cost $,
>                 � �but is
>                 � �not technically challenging. So, if I want to host
>                 a region like
>                 � �that... sure it will cost me, but the simulation
>                 will be consistent
>                 � �and users will be able to participate equally,
>                 regardless of the
>                 � �capabilities of their individual asset services.
>
>
>
>
>                 � �On Fri, Apr 1, 2011 at 11:55 PM, Morgaine
>                 � �<[email-masked]
>                 <mailto:[email-masked]>
>                 � �<mailto:[email-masked]
>                 <mailto:[email-masked]>>> wrote:
>                 � �> Every design choice results in a trade-off,
>                 Vaughn, improving
>                 � �one thing at
>                 � �> the expense of something else. �If every time we
>                 offered a
>                 � �service we had to
>                 � �> inform its users about the downsides of all the
>                 trade-offs we
>                 � �have made,
>                 � �> they would have an awful lot to read. ;-)
>                 � �>
>                 � �> The specific trade-off that you are discussing is no
>                 � �different. �A region
>                 � �> that proxies all content has the "benefit" of
>                 acquiring control
>                 � �from the
>                 � �> asset servers over the items in the region, so
>                 that it can
>                 � �ensure that
>                 � �> everyone in the region not only obtains the items
>                 but obtains
>                 � �the same items
>                 � �> as everyone else. �That does indeed provide a
>                 greater guarantee of
>                 � �> consistency than a deployment in which the region
>                 only passes
>                 � �asset URIs to
>                 � �> clients who then fetch the items from asset services
>                 � �separately. �As always
>                 � �> though, it's a trade-off, since the proxied
>                 design has very
>                 � �poor scalability
>                 � �> compared to the distributed one.
>                 � �>
>                 � �> If we're going to warn users of the potential for
>                 inconsistency
>                 � �in the
>                 � �> distributed deployment as you suggest, are we
>                 also going to
>                 � �warn them of
>                 � �> non-scalability in the proxied one? �I really
>                 don't see much
>                 � �merit in the
>                 � �> idea of warning about design choices. �Many such
>                 choices are
>                 � �technical, and
>                 � �> the issues are quite likely to be of little
>                 interest to
>                 � �non-technical users
>                 � �> anyway. �In any case, the better services are
>                 likely to provide
>                 � �such
>                 � �> information in their online documentation, I
>                 would guess.
>                 � �>
>                 � �> You mentioned users "voting with their feet" or
>                 choosing to
>                 � �accept the risk
>                 � �> of inconsistency. �Well that will happen anyway,
>                 when services
>                 � �fail and
>                 � �> users get annoyed. �If some asset services refuse
>                 to send the
>                 � �requested
>                 � �> items to some users, those services will get a
>                 bad reputation
>                 � �and people
>                 � �> will choose different asset services instead.
>                 �Likewise, if a
>                 � �world service
>                 � �> proxies everything and so it can't handle a large
>                 number of
>                 � �assets or of
>                 � �> people, users will get annoyed at the lag and will go
>                 � �elsewhere. �This user
>                 � �> evaluation and "voting with their feet" happens
>                 already with
>                 � �online services
>                 � �> all over the Internet, and I am sure that this
>                 human process
>                 � �will continue
>                 � �> to work when the services are asset and region
>                 services.
>                 � �>
>                 � �> Back in September 2010, I wrote this post which
>                 proposes that
>                 � �we use in
>                 � �> VWRAP a form of asset addressing that provides
>                 massive
>                 � �scalability at the
>                 � �> same time as a very high degree of resilience --
>                 � �>
>                 �
>                 �http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html
>                 � �. �It is
>                 � �> based on the concept of the URI containing a host
>                 part and a
>                 � �hash part,
>                 � �> where the hash is generated (once, at the time of
>                 storage to
>                 � �the asset
>                 � �> service) using a specified digest algorithm over
>                 the content of
>                 � �the asset
>                 � �> being referenced. �You may wish to note that if
>                 this design
>                 � �were used, the
>                 � �> failure of an asset service to deliver a
>                 requested item would
>                 � �result in a
>                 � �> failover request for the item to one or more
>                 backup services,
>                 � �using the same
>                 � �> hash part but with a different host address.
>                 � �>
>                 � �> This can go some way towards overcoming the
>                 problem that you
>                 � �think might
>                 � �> occur when assets are fetched by clients from
>                 asset services
>                 � �directly.
>                 � �> Although it won't help when the missing item is
>                 available from
>                 � �only a single
>                 � �> asset service, it will help in many other cases,
>                 and it will
>                 � �compensate for
>                 � �> service failures and network outages
>                 automatically at the same
>                 � �time.
>                 � �>
>                 � �> PS. This design for hash-based asset addressing
>                 is already
>                 � �being tested by
>                 � �> Mojito Sorbet in her experimental world and
>                 client. �It would give
>                 � �> VWRAP-based worlds an improved level of service
>                 availability,
>                 � �so I think it
>                 � �> should be a core feature of our protocol.
>                 � �>
>                 � �>
>                 � �> Morgaine.
>                 � �>
>                 � �>
>                 � �>
>                 � �>
>                 � �> ===========================
>                 � �>
>                 � �> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca
>                 � �<[email-masked]
>                 <mailto:[email-masked]>
>                 <mailto:[email-masked]
>                 <mailto:[email-masked]>>>
>                 � �> wrote:
>                 � �>>
>                 � �>> This is a question i discussed with Morgaine
>                 off-list a while
>                 � �ago (I
>                 � �>> intended to send it to the list but pushed the
>                 wrong button...) I
>                 � �>> think we need to address this problem, and
>                 decide how to deal
>                 � �with it.
>                 � �>>
>                 � �>> �In Davids deployment draft, section 7.3.1.1 an
>                 overview is
>                 � �given van
>                 � �>> ways to deliver content to the region. One way
>                 is only passing a
>                 � �>> capability that allows access to (part of) the
>                 resource:
>                 � �>>
>                 � �>> � � � � � 7.3.1.1. �Content delivery models
>                 � �>> � � � � � A range of possible represenations can
>                 be passed to
>                 � �a region for
>                 � �>> � � � � � simulation. [...] The other end of the
>                 delivery spectrum
>                 � �>> involves passing
>                 � �>> � � � � � only a URI or capability used to
>                 access the rendering
>                 � �>> information and a
>                 � �>> � � � � � collision mesh,and related data for
>                 physical simulation.
>                 � �>> � � � � � In such a model, the client is
>                 responsible for
>                 � �fetching the
>                 � �>> additional
>                 � �>> � � � � � information needed to render the
>                 item's visual
>                 � �presence from a
>                 � �>> separate
>                 � �>> � � � � � service. �This fetch can be done
>                 *under the
>                 � �credentials of the
>                 � �>> end user*
>                 � �>> � � � � � viewing the material [my emphasis--VD]
>                 , and
>                 � �divorces the
>                 � �>> simulation from
>                 � �>> � � � � � the trust chain needed to manage
>                 content. �Any
>                 � �automation
>                 � �>> is done on a
>                 � �>> � � � � � separate host which the content
>                 creator or owner trusts,
>                 � �>> interacting with the
>                 � �>> � � � � � object through remoted interfaces.
>                 � �>>
>                 � �>> �I can see the need for such a setup, however, i
>                 feel we are
>                 � �>> unpleasantly close to a situation were the
>                 coherence of the
>                 � �simulation
>                 � �>> falls apart.
>                 � �>> In this deployment pattern the region advertises
>                 the presence
>                 � �of the
>                 � �>> asset, and *some* clients will be able to get it
>                 as expected,
>                 � �while
>                 � �>> -based on the arbitrary whims of the asset
>                 service- others
>                 � �might not.
>                 � �>>
>                 � �>> My hope would be that after the asset server
>                 provides the
>                 � �region with
>                 � �>> the capability to get the asset, it gives up
>                 control. That
>                 � �would mean
>                 � �>> that if the client finds the inventory server is
>                 unwilling to
>                 � �serve
>                 � �>> the content - in spire of the region saying it
>                 is present-,
>                 � �the client
>                 � �>> should be able to turn around ask the *region*
>                 for the asset,
>                 � �(and get
>                 � �>> is after all).
>                 � �>>
>                 � �>> �If that is not the case, -and there are
>                 probably good reasons
>                 � �for the
>                 � �>> deployment pattern as described- �shouldn't we
>                 *warn* clients
>                 � �that the
>                 � �>> region might be inconsistent, so the users
>                 behind the client
>                 � �can vote
>                 � �>> with their feet, (or take the risk)?
>                 � �>>
>                 � �>> --Vaughn
>                 � �>> _______________________________________________
>                 � �>> vwrap mailing list
>                 � �>> [email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>                 � �>> https://www.ietf.org/mailman/listinfo/vwrap
>                 � �>
>                 � �>
>                 � �> _______________________________________________
>                 � �> vwrap mailing list
>                 � �> [email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>                 � �> https://www.ietf.org/mailman/listinfo/vwrap
>                 � �>
>                 � �>
>
>
>
>             �

--

---

From: Morgaine <[email-masked]>
Date: Sun, 3 Apr 2011 18:33:14 +0100

"Agent Domain" more or less ceased to exist in practice when David pointed
out very eloquently that the emperor had no clothes.  (Same for "Region
Domain".)

I think we mostly talk about the Agent Service and Region Service these
days.  The "domain" was just a fluffy cloud that someone once drew on a
whiteboard, but which never actually existed.

Morgaine.

====================

On Sun, Apr 3, 2011 at 6:20 PM, Dzonatas Sol <[email-masked]> wrote:

> client contacts the asset services now in the regions. The newer issue is to
> unitize that asset services. Since their is proprietary (legacy) code then
> we can't expect that to change, and some form of proxy is of need. Whatever
> works best, I tried to narrow it down to suggestions here.
>
> Eventually, the agent domain is ideal to handle the direction of the asset
> services. This concept, unfortunately, ended support awhile ago with changes
> in LL.
> I'd imagine the agent domain could grow out of unitized versions of asset
> services. Despite that, I think that concept helps view where we were at in
> discussion and what didn't happen.
>
> Vaughn Deluca wrote:
>
>> Hi�Dzonatas
>>
>> terms�?,
>> If i want to read up on how the�asset server may proxy the simulator, what
>> On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol <[email-masked] <mailto:

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 03 Apr 2011 10:38:06 -0700

I prefer the visualization of "domains" because those fluffy clouds 
really help those that don't do well with figure-of-speech "services."

Morgaine wrote:
> "Agent Domain" more or less ceased to exist in practice when David 
> pointed out very eloquently that the emperor had no clothes.  (Same 
> for "Region Domain".)
>
> I think we mostly talk about the Agent Service and Region Service 
> these days.  The "domain" was just a fluffy cloud that someone once 
> drew on a whiteboard, but which never actually existed.
>
>
> Morgaine.
>
>
>
>
> ====================
>
> On Sun, Apr 3, 2011 at 6:20 PM, Dzonatas Sol <[email-masked] 
>     Probably easy as suggested in other terms here on this list, as
>     how the client contacts the asset services now in the regions. The
>     newer issue is to unitize that asset services. Since their is
>     proprietary (legacy) code then we can't expect that to change, and
>     some form of proxy is of need. Whatever works best, I tried to
>     narrow it down to suggestions here.
>
>     Eventually, the agent domain is ideal to handle the direction of
>     the asset services. This concept, unfortunately, ended support
>     awhile ago with changes in LL.
>     And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset
>     (warn: unstructured collaborative notes, dumped on me and I tried
>     to fix)
>
>     I'd imagine the agent domain could grow out of unitized versions
>     of asset services. Despite that, I think that concept helps view
>     where we were at in discussion and what didn't happen.
>
>     Vaughn Deluca wrote:
>
>         Hi�Dzonatas
>
>         Can you expand on that, what would be needed for legacy
>         support in VWAP terms�?,
>         If i want to read up on how the�asset server may proxy the
>         simulator, what would you recommend me to read?
>
>         -- Vaughn
>
>         On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol
>                    > Both worlds and asset services may include
>         commercial,
>                    community, and personal services
>
>                    Totally agree, and a proxying model could and
>         should also
>                    take advantage of parallelism.
>
>                        <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>
>
>         <mailto:[email-masked]>>>> wrote:
>
>                        <mailto:[email-masked]
>         <mailto:[email-masked]>>
>                        <mailto:[email-masked]
>         <mailto:[email-masked]>>>> wrote:
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>>>>
>                        � �> wrote:
>                        � �>>
>                        <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>
>                        <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>

--

---

From: Morgaine <[email-masked]>
Date: Sun, 3 Apr 2011 19:31:57 +0100

We have no "figure-of-speech services" in VWRAP.  Our services are running
processes, they have network endpoints, and they talk a network protocol.

Concepts can be very useful, and I regularly draw fluffy clouds that
represent the concept behind something concrete.

Where concepts are not useful is when they denote something that doesn't
actually exist, like say phlogiston, God, or Agent Domain, because this just
makes them a hindrance to further progress.  Humanity suffers from this a
lot.

Philosophy aside, we want our Agent Service to be totally concrete, with a
network API and well defined semantics.  The domain concept does not get us
there.

Morgaine.

==================

On Sun, Apr 3, 2011 at 6:38 PM, Dzonatas Sol <[email-masked]> wrote:

> I prefer the visualization of "domains" because those fluffy clouds really
> help those that don't do well with figure-of-speech "services."
>
>
> Morgaine wrote:
>
>> On Sun, Apr 3, 2011 at 6:20 PM, Dzonatas Sol <[email-masked] <mailto:

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 3 Apr 2011 20:38:16 +0200

Thanks for the pointers.  I have a  busy week in RL in front of me, so i
wont have to much time to respond the next few days, however, i intend to
start doing the following things:

- Produce a visual that reflects my thinking, i.e. an illustration of my
response to Morgaine's itemlist  above.
- Read up on the older notes, as well as  more reading in the list archive
- Try to make a summary for the wiki

Regarding the use of domain, I think services are eventually what counts,
but its all terminology. The way I read the AWG diagrams is that the agent
domain is actually a cluster of tightly integrated services. When the
functionality of each sub-service is described properly and with uniform
interfaces the domain will slowly dissolve. But let not get ahead of out
selfs. We should put up some clear descriptions on the wiki for our views on
this, and *after* that we can decide what we need and what can go.

Its been a very useful and illuminating weekend for me, and i am a lot more
optimistic about the future of vwrap than two weeks ago.

-- Vaughn

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 03 Apr 2011 11:49:01 -0700

Visual people don't do well with "figure-of-speech" and such semantics. 
Those that prefer such semantics usually don't either don't recognize 
this or treat visual people as in need of accessibilities. We are not 
dumb. It doesn't get "you" their... it gets "us" there if you 
acknowledge these differences in people. Don't rely on such semantics, 
as to visual people that is just nonsense (being not useful). To visual 
people, every word carries its complete meanings and no less. To those 
that prefer "figure-of-speech" (auditory and kinetic types) they imply 
less that means nothing to visual people.

Also, do note that your message below seems to mock visual people as 
"hindrance to further progress". =(

I hope you reconsider your approach, Morgaine. Not often do people want 
to categorize accessibilities and such issues.

Morgaine wrote:
> We have no "figure-of-speech services" in VWRAP.  Our services are 
> running processes, they have network endpoints, and they talk a 
> network protocol.
>
> Where concepts are not useful is when they denote something that 
> doesn't actually exist, like say phlogiston, God, or Agent Domain, 
> because this just makes them a hindrance to further progress.  
> Humanity suffers from this a lot.
>
> Philosophy aside, we want our Agent Service to be totally concrete, 
> with a network API and well defined semantics.  The domain concept 
> does not get us there.
>
>
> Morgaine.
>
>
>
>
> ==================
>
> On Sun, Apr 3, 2011 at 6:38 PM, Dzonatas Sol <[email-masked] 
>     I prefer the visualization of "domains" because those fluffy
>     clouds really help those that don't do well with figure-of-speech
>     "services."
>
>
>     Morgaine wrote:
>
>         "Agent Domain" more or less ceased to exist in practice when
>         David pointed out very eloquently that the emperor had no
>         clothes.  (Same for "Region Domain".)
>
>         I think we mostly talk about the Agent Service and Region
>         Service these days.  The "domain" was just a fluffy cloud that
>         someone once drew on a whiteboard, but which never actually
>         existed.
>
>
>         Morgaine.
>
>
>
>
>         ====================
>
>         On Sun, Apr 3, 2011 at 6:20 PM, Dzonatas Sol
>            And:
>         http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset
>         <mailto:[email-masked] <mailto:[email-masked]>>
>                <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>
>                           > when designing for scalability, the model
>         to bear in
>                           mind is ...
>
>                           Well, there are a lot of different models to
>         keep
>                in mind,
>                           Yes, yes and yes. I'm particularly concerned
>         about
>                how the
>                           > a proxying region, which would get slammed
>         for every
>                           asset worn by every avatar present.
>
>                           the region need to be scaled to meet the
>         demands of
>                that
>         scripting,
>                           shared by different regions. (Server-side
>         scripting
>                is a
>                           I think what you're saying is: "It costs a
>         lot of
>                money to
>                           build a scalable asset service, but if
>         assets are
>                spread
>                           But that's not quite right. You're opening
>         up every
>                asset
>                           server to the VW equivalent of being
>         slashdotted,
>                so are
>                           scalable and handle a lot of bandwith and
>         network
>                traffic?
>                           creativity). Creating a high bar to provide
>         asset
>                services
>                               travelers whose inventories contain
>         assets from
>                many
>                               their "worn" assets (the only ones of
>         interest
>                to the
>                               spread widely across the Internet. �The
>         fetches
>                by the
>                               server loading because they are both
>         spread out
>                over
>                               region, which would get slammed for
>         every asset
>                worn
>                               today's kind. �We've hit the ceiling
>         already on
>                region
>                               scalability done that way. �There is
>         nowhere to
>                go in
>                               that direction at all beyond improving
>         the code
>                like
>                               Intel demonstrated, and that work is
>         subject to
>                a law
>                               of diminishing returns.
>
>                               This is why we have to go parallel, and
>         I think
>                you're
>                               the load across more and more asset
>         services,
>                we are
>                               already out there on the Internet, at
>         least in
>                respect
>                               community and private resources the
>         commercial
>                asset
>                               services leap, but the power of each one
>         will
>                rocket
>         <mailto:[email-masked]>> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>                <mailto:[email-masked] <mailto:[email-masked]>>
>
>         <mailto:[email-masked]>>>>> wrote:
>
>                               � �to be scaled to meet that asset
>         demand too,
>                but it
>                               already has to be
>                               � �not technically challenging. So, if I
>         want
>                to host
>                               a region like
>         <mailto:[email-masked]>>>
>                               �
>         �<mailto:[email-masked]
>         <mailto:[email-masked]>>>>> wrote:
>                               � �> the expense of something else. �If
>         every
>                time we
>                               offered a
>                               � �service we had to
>                               � �> consistency than a deployment in
>         which the
>                region
>                               only passes
>                               � �asset URIs to
>                               � �> of inconsistency. �Well that will
>         happen
>                anyway,
>                               when services
>                               � �fail and
>                               � �> users get annoyed. �If some asset
>         services
>                refuse
>                               to send the
>                               � �requested
>                               � �> proxies everything and so it can't
>         handle
>                a large
>                               number of
>                               � �assets or of
>                               � �> people, users will get annoyed at
>         the lag
>                and will go
>                               � �elsewhere. �This user
>                               � �> Back in September 2010, I wrote
>         this post
>                which
>                               proposes that
>                               � �we use in
>                               � �> based on the concept of the URI
>         containing
>                a host
>                               part and a
>                               � �hash part,
>                               � �> where the hash is generated (once,
>         at the
>                time of
>                               storage to
>                               � �the asset
>                               � �> asset service, it will help in many
>         other
>                cases,
>                               and it will
>                               � �compensate for
>         <mailto:[email-masked]>>>>>
>                               � �> wrote:
>                               � �>>
>                               � �>> � � � � � simulation. [...] The
>         other end
>                of the
>                               delivery spectrum
>                               � �>> involves passing
>                               � �>> asset, and *some* clients will be
>         able to
>                get it
>                               as expected,
>                               � �while
>                               � �>> [email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>                               <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>
>
>                               � �>>
>                               � �> [email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>                               <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>
>
>                               � �>

--

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 03 Apr 2011 12:08:13 -0700

Also, most "figure-of-speech" is conceptual in the way it narrows 
meanings of words that make sense to auditory people and the semantics 
they prefer. Visual people prefer complete ideas rather than such 
conceptual sentients. This is why visual people tend to write with less 
words and more meanings while auditory people tend to write full length 
figure of speech and less meaning. It means more to auditory people.

Not to get off track here, I did take college classes on that, which 
corrected my English teachers (despite their philosophy, ugh!) Their 
ploy to "correct programmer English" backfired with 100% technically 
correct English and no figure-of-speech written papers. They hated it. 
I've relaxed since then, and I hope you do, too.

--

---

From: Morgaine <[email-masked]>
Date: Sun, 3 Apr 2011 20:42:47 +0100

I'm afraid you misunderstand the issue, Dzonatas.  I'll add a bit of
background.

This has nothing to do with visual versus graphical presentation.  I'm a big
fan of both, and like yourself I think spatially most of the time about
architectures, which is a graphic form.  Likewise, it has nothing to do with
accessibility whatsoever, of which I've been a very enthusiastic proponent
in Second Life for many years.

The only thing with which the "domain" argument is concerned is whether the
concept reflects something useful in VWRAP that we can observe, query,
interact with, or design a protocol around.  The answer is "No" on all these
counts for "Agent Domain" in VWRAP, because it refers to a concept in OGP
that denied interop, and it does not apply to us.

As a result, far from helping anyone to understand the VWRAP architecture,
all it does is increase the amount of confusion surrounding VWRAP, because
it does not reflect anything useful about what we are trying to implement.

The nearest we get in VWRAP to something that might have been conceived
originally as the "Agent Domain" in OGP is roughly "The set of places and
items and resources that this world will permit an agent to visit or
interact with ", which is approximately the same thing as saying "the closed
walled garden".  It is a singularly counter-productive concept for a group
that has the important goal of achieving interop between worlds.

So no, it's not helpful, either visually or otherwise.  The term is just
another obstacle on the road to VW interop.  That OGP whiteboard never had
other fluffy clouds on it labeled "Virtual world B", "Virtual world C", and
so on.  The concept of interop between worlds was denied, because Agent
Domain controlled access to Region Domains, and so nothing outside AD+RD
existed in OGP.

But we are not designing OGP, we are designing VWRAP, a set of protocols
that embraces interoperation between worlds as well.  That is why the Agent
Domain does not exist as a useful concept in this work.  It elevates world
closure, negates interoperation, and does not even admit other worlds into
the picture, because Agent Domain is defined to exclude them.

It's a very bad idea, both in text and as fluffy clouds.

Morgaine.

======================

On Sun, Apr 3, 2011 at 7:49 PM, Dzonatas Sol <[email-masked]> wrote:

> Those that prefer such semantics usually don't either don't recognize this
> or treat visual people as in need of accessibilities. We are not dumb. It
> doesn't get "you" their... it gets "us" there if you acknowledge these
> differences in people. Don't rely on such semantics, as to visual people
> that is just nonsense (being not useful). To visual people, every word
> carries its complete meanings and no less. To those that prefer
> "figure-of-speech" (auditory and kinetic types) they imply less that means
> nothing to visual people.
>
> I hope you reconsider your approach, Morgaine. Not often do people want to
> categorize accessibilities and such issues.
>
> Morgaine wrote:
>
>> On Sun, Apr 3, 2011 at 6:38 PM, Dzonatas Sol <[email-masked] <mailto:

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 03 Apr 2011 13:08:57 -0700

As stated, "it didn't happen." The concepts and ideas are still iconic 
natured and useful as such. It's iconic usefulness as like that of 
infinite tense that all English teachers want their students to write in 
& with figure-of-speech, its the wrong way. That is the nature of 
English infinite tense. All other tenses are correct, and teachers 
expect you to "correct" infinite tense, yet they don't teach that. 
That's the basis of sentience. Infinite tense is logically always in error.

Now with that in mind, "we" did not misunderstand the issues. Don't 
blame others until you look in the mirror more. What makes sense to you 
doesn't guarantee it makes sense to everybody else. The "graphic form" 
does not denote sense to visual people! Don't assume this! Like I said, 
visual people need complete ideas. Visual people don't remember 
dictionary definitions as much as auditory people don't remember graphic 
notations. It's because 60% of the people are auditory (they remember 
active speech) they are at constant battle with themselves in attempts 
to help the other 40% everywhere they don't need help -- is why there is 
ANY miscomprehension.

Visual people find it completely dumb idea to have dictionaries full 
words that have any prefixes or suffixes, as that is wasted resources. 
Only the root words with possible prefixes and suffixes are of need. The 
reason why they don't exist this way is because of "figure-of-speech" 
and proof of that 60%. Unless you are somehow smarter than the best and 
the brightest, I doubt you can solely point out bad ideas such as 
dictionaries that list every combination of root words with every 
possible suffix and prefix individually such that basically kills us off 
slowly with lack of symbiotic flow due to trees used for the numerous 
pages published as scholarly works. It's a killing.

Morgaine wrote:
> This has nothing to do with visual versus graphical presentation.  I'm 
> a big fan of both, and like yourself I think spatially most of the 
> time about architectures, which is a graphic form.  Likewise, it has 
> nothing to do with accessibility whatsoever, of which I've been a very 
> enthusiastic proponent in Second Life for many years.
>
> The only thing with which the "domain" argument is concerned is 
> whether the concept reflects something useful in VWRAP that we can 
> observe, query, interact with, or design a protocol around.  The 
> answer is "No" on all these counts for "Agent Domain" in VWRAP, 
> because it refers to a concept in OGP that denied interop, and it does 
> not apply to us.
>
> As a result, far from helping anyone to understand the VWRAP 
> architecture, all it does is increase the amount of confusion 
> surrounding VWRAP, because it does not reflect anything useful about 
> what we are trying to implement.
>
> The nearest we get in VWRAP to something that might have been 
> conceived originally as the "Agent Domain" in OGP is roughly "The set 
> of places and items and resources that this world will permit an agent 
> to visit or interact with ", which is approximately the same thing as 
> saying "the closed walled garden".  It is a singularly 
> counter-productive concept for a group that has the important goal of 
> achieving interop between worlds.
>
> So no, it's not helpful, either visually or otherwise.  The term is 
> just another obstacle on the road to VW interop.  That OGP whiteboard 
> never had other fluffy clouds on it labeled "Virtual world B", 
> "Virtual world C", and so on.  The concept of interop between worlds 
> was denied, because Agent Domain controlled access to Region Domains, 
> and so nothing outside AD+RD existed in OGP.
>
> But we are not designing OGP, we are designing VWRAP, a set of 
> protocols that embraces interoperation between worlds as well.  That 
> is why the Agent Domain does not exist as a useful concept in this 
> work.  It elevates world closure, negates interoperation, and does not 
> even admit other worlds into the picture, because Agent Domain is 
> defined to exclude them.
>

--

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 03 Apr 2011 13:35:56 -0700

One more thing, in regards to "It's a killing..."...  why do you think 
automation and virtual worlds exist in the first place?

If your answer is anything near virtualization in ways that become 
turtles upon turtles (or VWs in VWs)... well... readjust your 
perspective back to "save the environment" and reboot from there.

Being able to model and manufacturer without paperwork and without 
environmental damage has and remains the #1 reason (despite LL's call 
for "Fast, Fun, S...").

 From that perspective, "asset" has wide-range of meanings that often 
get narrowed carelessly for the "fun of it". Many often go backwards 
before they know all meaning of assets. Any system that demonstrates 
single-entry derived bank automation is obviously backwards; it is quick 
to implement, costs too much in the end to upgrade, and always fails.

Dzonatas Sol wrote:
> infinite tense that all English teachers want their students to write 
> in & with figure-of-speech, its the wrong way. That is the nature of 
> blame others until you look in the mirror more. What makes sense to 
> you doesn't guarantee it makes sense to everybody else. The "graphic 
> form" does not denote sense to visual people! Don't assume this! Like 
> I said, visual people need complete ideas. Visual people don't 
> remember dictionary definitions as much as auditory people don't 
> remember graphic notations. It's because 60% of the people are 
> auditory (they remember active speech) they are at constant battle 
> with themselves in attempts to help the other 40% everywhere they 
> don't need help -- is why there is ANY miscomprehension.
>
> Only the root words with possible prefixes and suffixes are of need. 
> The reason why they don't exist this way is because of 
> "figure-of-speech" and proof of that 60%. Unless you are somehow 
> smarter than the best and the brightest, I doubt you can solely point 
> out bad ideas such as dictionaries that list every combination of root 
> words with every possible suffix and prefix individually such that 
> basically kills us off slowly with lack of symbiotic flow due to trees 
> used for the numerous pages published as scholarly works. It's a killing.
>
>
> Morgaine wrote:
>> This has nothing to do with visual versus graphical presentation.  
>> I'm a big fan of both, and like yourself I think spatially most of 
>> the time about architectures, which is a graphic form.  Likewise, it 
>> has nothing to do with accessibility whatsoever, of which I've been a 
>> very enthusiastic proponent in Second Life for many years.
>>
>> because it refers to a concept in OGP that denied interop, and it 
>> does not apply to us.
>>
>> of places and items and resources that this world will permit an 
>> agent to visit or interact with ", which is approximately the same 
>> thing as saying "the closed walled garden".  It is a singularly 
>> work.  It elevates world closure, negates interoperation, and does 
>> not even admit other worlds into the picture, because Agent Domain is 
>> defined to exclude them.
>>

--

---

From: Fleep Tuque <[email-masked]>
Date: Sun, 3 Apr 2011 20:02:17 -0400

On a purely academic side note, the theory of "learning styles" has been
disputed and some would even say debunked.  Current research shows that
depending upon the context and activity we're involved with and our specific
physical abilities, people generally all learn in visual, auditory,
kinesthetic, etc. ways.  Unfortunately the website for the primary journal
article I wanted to reference appears to be down at the moment, but see
http://chronicle.com/article/Matching-Teaching-Style-to-/49497/ for a pretty
good explanation.

I admit that I don't know enough VWRAP history to fully understand the crux
of this debate, but I'm having a hard time drawing the connection between
criticism of how a term term like "Agent Domain" has been/is being used and
how that relates to accessibility issues.  I hope moving forward we're all
careful about being critical of ideas versus criticizing a person's
abilities and perhaps we can dial back the rhetoric a bit to keep the
discussion focused and positive.

Sincerely,

- Chris/Fleep

Chris M. Collins (SL: Fleep Tuque)
Project Manager, UC Second Life
Second Life Ambassador, Ohio Learning Network
UCit Instructional & Research Computing
University of Cincinnati
406E Zimmer Hall
PO Box 210088
Cincinnati, OH 45221-0088
(513)556-3018
[email-masked]

UC Second Life:   http://homepages.uc.edu/secondlife
OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php

On Sun, Apr 3, 2011 at 4:08 PM, Dzonatas Sol <[email-masked]> wrote:

> natured and useful as such. It's iconic usefulness as like that of infinite
> tense that all English teachers want their students to write in & with
> figure-of-speech, its the wrong way. That is the nature of English infinite
> tense. All other tenses are correct, and teachers expect you to "correct"
> infinite tense, yet they don't teach that. That's the basis of sentience.
> Infinite tense is logically always in error.
>
> Now with that in mind, "we" did not misunderstand the issues. Don't blame
> others until you look in the mirror more. What makes sense to you doesn't
> guarantee it makes sense to everybody else. The "graphic form" does not
> denote sense to visual people! Don't assume this! Like I said, visual people
> need complete ideas. Visual people don't remember dictionary definitions as
> much as auditory people don't remember graphic notations. It's because 60%
> of the people are auditory (they remember active speech) they are at
> constant battle with themselves in attempts to help the other 40% everywhere
> they don't need help -- is why there is ANY miscomprehension.
>
> Visual people find it completely dumb idea to have dictionaries full words
> that have any prefixes or suffixes, as that is wasted resources. Only the
> root words with possible prefixes and suffixes are of need. The reason why
> they don't exist this way is because of "figure-of-speech" and proof of that
> 60%. Unless you are somehow smarter than the best and the brightest, I doubt
> you can solely point out bad ideas such as dictionaries that list every
> combination of root words with every possible suffix and prefix individually
> such that basically kills us off slowly with lack of symbiotic flow due to
> trees used for the numerous pages published as scholarly works. It's a
> killing.
>
>
>
> Morgaine wrote:
>
>> This has nothing to do with visual versus graphical presentation.  I'm a
>> big fan of both, and like yourself I think spatially most of the time about
>> The only thing with which the "domain" argument is concerned is whether
>> the concept reflects something useful in VWRAP that we can observe, query,

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 03 Apr 2011 17:42:43 -0700

It's hard to consider deaf and blind people as only theoritically deaf 
and theoretically blind. The differences between sight & sound is beyond 
theory.

Consider that many have tried to falsify "learning styles" or other 
nature of such visual, auditory, kinetic, and kinesthetic, and believed 
they have debunked such issues, only makes it official science. Science 
is based on falsifiable claims and not unfalsifiable claims. Every 
scientist either goes through such evil or checks out with their PhD 
(the universities' gamble/gambits), as their claims are philosophy until 
otherwise official. Those are the obvious limits of science.

Usual "learning styles" only relate to the first 20 years (applied 
limits), and then after that more official science backs up the cases. 
It's just not easy to debunk real world experiences outside of 
educational institutions. Either people are born as experts as beings 
that learn the same way, or we are all learn different. Neither have 
been proven, and the link you gave doesn't debunk either. There are 
"strength" groups defined, however. By the tried and proven tests 
(psychology) that 60% auditory is very definitive. Given that majority 
rules usually means auditory wins@>50%, its hard for any other 
"strength" group to make their case. That's enough signifigant enough to 
remain useful weight in various cases in court where it is mainly based 
on "hearings". Court only gives interpreters to those that are obvious 
in need of them. Any effort to debunk these differences only make it 
harder for those that are not so obviously different from "hearing" 
enabled. Given that courts still haven't changed, it remains that 'hard 
to draw such connections' even in such cases.

Otherwise, more back on track, VWs have helped in many areas in regards 
to accessibilities. I just hate to detail every reason and make 
examples. Carefully, hope...

Fleep Tuque wrote:
> On a purely academic side note, the theory of "learning styles" has 
> been disputed and some would even say debunked. �Current research 
> shows that depending upon the context and activity we're involved with 
> and our specific physical abilities, people generally all learn in 
> visual, auditory, kinesthetic, etc. ways. �Unfortunately the website 
> for the primary journal article I wanted to reference appears to be 
> down at the moment, but 
> see�http://chronicle.com/article/Matching-Teaching-Style-to-/49497/�for 
> a pretty good explanation. �
>
> I admit that I don't know enough VWRAP history to fully understand the 
> crux of this debate, but�I'm having a hard time drawing the connection 
> between criticism of how a term term like "Agent Domain" has been/is 
> being used and how that relates to accessibility issues. �I hope 
> moving forward we're all careful about being critical of ideas versus 
> criticizing a person's abilities and perhaps we can dial back the 
> rhetoric a bit to keep the discussion focused and positive.
>
>
> Sincerely,
>
> - Chris/Fleep
>
>
> Project Manager, UC Second Life�
> Second Life Ambassador, Ohio Learning Network�
> University of Cincinnati�
> 406E Zimmer Hall
> PO Box 210088
> [email-masked] <mailto:[email-masked]>
>
> UC Second Life: � http://homepages.uc.edu/secondlife
> On Sun, Apr 3, 2011 at 4:08 PM, Dzonatas Sol <[email-masked] 
>     As stated, "it didn't happen." The concepts and ideas are still
>     iconic natured and useful as such. It's iconic usefulness as like
>     that of infinite tense that all English teachers want their
>     students to write in & with figure-of-speech, its the wrong way.
>     That is the nature of English infinite tense. All other tenses are
>     correct, and teachers expect you to "correct" infinite tense, yet
>     they don't teach that. That's the basis of sentience. Infinite
>     tense is logically always in error.
>
>     Now with that in mind, "we" did not misunderstand the issues.
>     Don't blame others until you look in the mirror more. What makes
>     sense to you doesn't guarantee it makes sense to everybody else.
>     The "graphic form" does not denote sense to visual people! Don't
>     assume this! Like I said, visual people need complete ideas.
>     Visual people don't remember dictionary definitions as much as
>     auditory people don't remember graphic notations. It's because 60%
>     of the people are auditory (they remember active speech) they are
>     at constant battle with themselves in attempts to help the other
>     40% everywhere they don't need help -- is why there is ANY
>     miscomprehension.
>
>     Visual people find it completely dumb idea to have dictionaries
>     full words that have any prefixes or suffixes, as that is wasted
>     resources. Only the root words with possible prefixes and suffixes
>     are of need. The reason why they don't exist this way is because
>     of "figure-of-speech" and proof of that 60%. Unless you are
>     somehow smarter than the best and the brightest, I doubt you can
>     solely point out bad ideas such as dictionaries that list every
>     combination of root words with every possible suffix and prefix
>     individually such that basically kills us off slowly with lack of
>     symbiotic flow due to trees used for the numerous pages published
>     as scholarly works. It's a killing.
>
>
>
>     Morgaine wrote:
>
>         I'm afraid you misunderstand the issue, Dzonatas. �I'll add a
>         bit of background.
>
>         This has nothing to do with visual versus graphical
>         presentation. �I'm a big fan of both, and like yourself I
>         think spatially most of the time about architectures, which is
>         a graphic form. �Likewise, it has nothing to do with
>         accessibility whatsoever, of which I've been a very
>         The only thing with which the "domain" argument is concerned
>         is whether the concept reflects something useful in VWRAP that
>         we can observe, query, interact with, or design a protocol
>         around. �The answer is "No" on all these counts for "Agent
>         Domain" in VWRAP, because it refers to a concept in OGP that
>         denied interop, and it does not apply to us.
>
>         surrounding VWRAP, because it does not reflect anything useful
>         about what we are trying to implement.
>
>         conceived originally as the "Agent Domain" in OGP is roughly
>         "The set of places and items and resources that this world
>         will permit an agent to visit or interact with ", which is
>         approximately the same thing as saying "the closed walled
>         garden". �It is a singularly counter-productive concept for a
>         group that has the important goal of achieving interop between
>         worlds.
>
>         So no, it's not helpful, either visually or otherwise. �The
>         term is just another obstacle on the road to VW interop. �That
>         OGP whiteboard never had other fluffy clouds on it labeled
>         "Virtual world B", "Virtual world C", and so on. �The concept
>         of interop between worlds was denied, because Agent Domain
>         controlled access to Region Domains, and so nothing outside
>         AD+RD existed in OGP.
>
>         protocols that embraces interoperation between worlds as well.
>         �That is why the Agent Domain does not exist as a useful
>         concept in this work. �It elevates world closure, negates
>         interoperation, and does not even admit other worlds into the
>         picture, because Agent Domain is defined to exclude them.
>

--

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 03 Apr 2011 17:59:59 -0700

Maybe I should note I'm also eager to see some VW that makes it possible 
for the deaf or of any such degree can use the VW as the courtroom and 
not have to deal with anything in terms of "hearing", that meaning, or 
anything that would be regarded as interpretation or translations. I 
know I'm not the only one, especially when people are serious to create 
such practice instead feel so alienated. (Or, feel alienated by any need 
to having to explain oneself... to any disability).

Of course, security is kept in mind between VWs & simulations.

Dzonatas Sol wrote:
> and theoretically blind. The differences between sight & sound is 
> beyond theory.
>
> nature of such visual, auditory, kinetic, and kinesthetic, and 
> believed they have debunked such issues, only makes it official 
> science. Science is based on falsifiable claims and not unfalsifiable 
> claims. Every scientist either goes through such evil or checks out 
> with their PhD (the universities' gamble/gambits), as their claims are 
> philosophy until otherwise official. Those are the obvious limits of 
> science.
>
> "strength" group to make their case. That's enough signifigant enough 
> to remain useful weight in various cases in court where it is mainly 
> based on "hearings". Court only gives interpreters to those that are 
> obvious in need of them. Any effort to debunk these differences only 
> make it harder for those that are not so obviously different from 
> "hearing" enabled. Given that courts still haven't changed, it remains 
> that 'hard to draw such connections' even in such cases.
>
> Otherwise, more back on track, VWs have helped in many areas in 
> regards to accessibilities. I just hate to detail every reason and 
> make examples. Carefully, hope...
>
> Fleep Tuque wrote:
>> shows that depending upon the context and activity we're involved 
>> with and our specific physical abilities, people generally all learn 
>> in visual, auditory, kinesthetic, etc. ways. �Unfortunately the 
>> website for the primary journal article I wanted to reference appears 
>> to be down at the moment, but 
>> I admit that I don't know enough VWRAP history to fully understand 
>> the crux of this debate, but�I'm having a hard time drawing the 
>> connection between criticism of how a term term like "Agent Domain" 
>> has been/is being used and how that relates to accessibility issues. 
>> �I hope moving forward we're all careful about being critical of 
>> ideas versus criticizing a person's abilities and perhaps we can dial 
>> back the rhetoric a bit to keep the discussion focused and positive.
>>
>>
>> Sincerely,
>>
>> - Chris/Fleep
>>
>>

--

---

From: Vaughn Deluca <[email-masked]>
Date: Fri, 8 Apr 2011 18:40:03 +0200

VWRAP services high level message flow (preliminary diagram draft) see

http://trac.tools.ietf.org/wg/vwrap/trac/attachment/wiki/Diagrams/VWRAP_FlowExample_VD1.pdf

The main reason that i am submitting this in spite of my lack of formal
expertise is that the group in my view badly needs a solid basis for
discussion and preventing endless repeating loops. This example is probably
wrong in many ways, but its better than what we have publicly available on
interop now (although Morgaine is working on something along the lines of
the recent discussions here)

I hope this diagram will give us a base for discussion. I could have done my
homework better by researching the old OGP stuff in more depth, and i
probably  will do so in the future , but for now I just tried to followed
the general principles as far as i understand them, to see what response
that yields from the group. In other words,I try to let the group educate me
:p

Note that in  my view all services are equal, in principle it does not
matter in what "domain" they run, since trust and policy are fully
localized. It is however very possible to have internal shortcuts in the
services to speed up processing.

In the example I opted for an external Agent service, but I could as well
have incorporated that in the set of local services. As indicated above all
services could also be run by different organisations, true to what VWRAP
stands for. Its all up to the deployer, including a user at home who might
want to run a full world for family and friends. Those friends might try to
use that agent service to venture out in the virtual universe.
I envision that the final identity  provider is external, using OpenID and
OAut  or whatever other  magic that I do not yet fully understand exists out
there.

The  example has 3 main purposes:
-  Provide a reference for discussion
- Illustrates the use case of tourism, and *true* interop.
- Illustrate consistency problems along the lines discussed  here higher up
in this tread, as well as the "slashdot" problem that Morgaine outlined so
clearly.

The message flow assumes an avatar already present in some region, (a small
scale local home region in this case, but that is by no means essential, it
could be a build in region in the viewer or a big commercial region). The
user is preparing for a trip to immersive world, and after some outfit
adjustments moves over.

Finally i apologize for for the simplistic notation used here. I simply add
the most relevant parameters passed in square brackets to a keyword
specifying the nature of the message. Please improve on that where needed.

So here we go, the avatar is  prepare for a visit to "immersive world"
0)  Viewer, here is an update of the state of the world your agent is in,
please render.
1)  Agent service, I will go in my Zodiac dress that i keep in the  "Amazing
assets" service.
2)  Asset service A, please send a cap for Z, here are my credentials
3)  Your fine, here is the cap
4)  Local region, can you please put this on my agent, i included the cap.
5)  Hello asset service A, i need Z, here is the cap
6)  Cap is good, data coming up, have fun.
7)  Agent service, your agent is now wearing Z
8)  Viewer, your avatar is now wearing Z
    User: Hmm, amazing inventory has not been *that* amazing lately. 'll
make a backup, just in case
9)  Hello asset service A, please send me a cap for Z, here are my
credentials
10) Your fine, here is the cap
11) Local asset storage, please store Z for me, here is the cap to get it
12) Hello asset service A, i want Z, here is the cap
13) Cap is good, data coming up, have fun.
14) Viewer, Z is now stored for you
    User: I am Ready!, Lets try to get to immersive world!
15) Hello immersive world, can i get in? Here are my credentials, and a list
of my stuff.
16) Asset service A, please send me a cap for X, here are my credentials (I
want this cap for consistency)
17) Your fine, here is the cap
18) Asset service B, please send me a cap for Y, here are my credentials (I
want this cap for consistency)
19) Very sorry, but your not one of us, you can't have Y
20) Asset service B, please send me a cap for Z, here are my credentials (I
want a cap for consistency)
[Region service: Timeout... amazing inventory must be overloaded.. oh
well... ]
21) Agent service, you wanted to send somebody over, here are your
permissions.
22) Viewer, you asked for a transfer try, here are your results
     User thinks:  Crap! Big asset service does not allow  me to take my
yellow stockings! And Amazing assets  failed to deliver my zodiac dress. At
least i made a backup of that dress!
23) 'll take the yellow stockings off...
24) ... done ('ll trash them here and now, forever, who needs stuff you
can't use!)
25) The zodiac dress was not delivered by Big assets service, but i have a
local copy!
26) Local Asset service, please send me Z, here are my credentials
27) I dont know you, but I 'll trust you, here is the cap, but you better
store the data, its single use, i need to protect myself.
28) Local region, can you please put this on my agent, i include the cap.
29) Local Asset service, i need Z, here is the cap
30) Cap is good, data coming up, have fun.
31) Cap was only good for one time, I made a copy, but my policy is to only
grant you fair use rights, at a later time i might even tell you to replace
the dress.
32) Viewer, you can wear Z for now, but the asset service granted only fair
use, i might ask you to replace the dress at a later time.
33) Ready at last! Off to immersive world!, I hope its not to crowded there
or 'll loose my dress...
34) Hello immersive world, here are my credentials, and a list of stuff i
want to bring
35) Hello asset service A, please send me a cap for X, here are my
credentials
    [darn, I should have kept that cap from last time..]
36) Your fine, here is the cap.
   [Region service finds fair-use warning on Z and decides to make its own
copy]
37) Hello Local region, can i still have Z? Here is the cap
38) Cap is still good, data coming up, have fun.
   [Region service stores asset in private storage, providing a cap to
replace the fair use one]
39) Agent service, you wanted to send somebody over, here are your
permissions & info.
40) Hello immersive world, just  get me there, and use what you can
41) Placement done, Z is currently buffered by us as wel, you need to get
details for X, have fun.
42) You are now in immersive world, your dress is buffered there as well,
but you need to get X!
43) Hello asset service A, i want X, here is the cap
44) Cap is good, data coming up, have fun.
45) Viewer, here is an update of the state of the world your agent is in,
please render.

As far as I can see this conforms fully to our charter, and i hope it is
possible to use large portions of the existing code bases. However, as said
above, i did not really try to capture the old thinking, and I also might
have misconceptions about the way to do these things in general.
Looking forward to constructive comments.

-- Vaughn

On Sun, Apr 3, 2011 at 8:38 PM, Vaughn Deluca <[email-masked]>wrote:

>>> On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol <[email-masked]<mailto:

---

From: Vaughn Deluca <[email-masked]>
Date: Fri, 8 Apr 2011 20:57:41 +0200

Drat!, I already found two editing mistakes, step 20 should address A, not B
and should read:
20) Asset service A, please send me a cap for Z, here are my credentials (I
want a cap for consistency)

And the same mixup in step 25: "Amzing Assets" should be mentioned instead
of "Big assets":
25) The zodiac dress was not delivered by Amzing assets, but i have a local
copy!

I will add an updated version of the description on the vwrap wiki

-- Vaughn

On Fri, Apr 8, 2011 at 6:40 PM, Vaughn Deluca <[email-masked]>wrote:

> I hope this diagram will give us a base for discussion. I could have done
> my homework better by researching the old OGP stuff in more depth, and i
> 1)  Agent service, I will go in my Zodiac dress that i keep in the
>  "Amazing assets" service.
> 15) Hello immersive world, can i get in? Here are my credentials, and a
> list of my stuff.
>> Its been a very useful and illuminating weekend for me, and i am a lot
>> more optimistic about the future of vwrap than two weeks ago.
>>
>> -- Vaughn
>>
>>
>>
>>> asset services. This concept, unfortunately, ended support awhile ago with
>>> changes in LL.

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 08 Apr 2011 12:00:47 -0700

I've read it, and off hand I would say the "flow" needs further 
definition. Not that you did anything wrong, it just something that 
happens more at the transfer layer from ReST and lower. All the arrows 
you have that go from the Local to External let's consider those 
"forward flow" and those that from from external to local as "reverse 
flow." This becomes more obvious for reasons why when firewalls and 
proxies are in the way and connections may need to exist in opposite of 
the flow. Between unidirectional and bidirectional flows is were this 
discussion digresses to vanilla HTTP/caps and not fully ReSTful as desired.

See also this doc on "forward/reverse" how Icesphere handles the 
implementation of bidirectional resources: 
http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Interface

I think you already see the higher-level request to begin capability, 
end capability, and determine if it needs to request capabilities. With 
bidirectional resources, there are less requests for capabilities and 
mainly need for digests of capabilities that begin and end. With 
unidirectional resources, there are needs to request capabilities, that 
(currently on servers) begin as private capabilities. Also with 
unidirectional resources, there are keep-alives and long-poll 
requirements on the resources, which isn't mandatory on bidirectional 
resources. Bidirectional resources can use more ReSTful credentials, so 
there would be no need to request capabilities (only need to know they 
are capable by the digests).

I imagine two big polygons around the Local and External areas on the 
diagrams, yet to further image the arrows on actual flow might not be so 
trivial as the desired flow noted. Then again, split the viewer out for 
local agent services and maybe it will appear trivial.

Vaughn Deluca wrote:
> The main reason that i am submitting this in spite of my lack of 
> formal expertise is that the group in my view badly needs a solid 
> basis for discussion and preventing endless repeating loops. This 
> example is probably wrong in many ways, but its better than what we 
> have publicly available on interop now (although Morgaine is working 
> on something along the lines of the recent discussions here) 
>
> I hope this diagram will give us a base for discussion. I could have 
> done my homework better by researching the old OGP stuff in more 
> depth, and i probably  will do so in the future , but for now I just 
> tried to followed the general principles as far as i understand them, 
> to see what response that yields from the group. In other words,I try 
> to let the group educate me :p
>
> localized. It is however very possible to have internal shortcuts in 
> the services to speed up processing. 
>
> In the example I opted for an external Agent service, but I could as 
> well have incorporated that in the set of local services. As indicated 
> above all services could also be run by different organisations, true 
> to what VWRAP stands for. Its all up to the deployer, including a user 
> at home who might want to run a full world for family and friends. 
> Those friends might try to use that agent service to venture out in 
> the virtual universe. 
> I envision that the final identity  provider is external, using OpenID 
> and OAut  or whatever other  magic that I do not yet fully understand 
> exists out there.
>
> - Illustrate consistency problems along the lines discussed  here 
> higher up in this tread, as well as the "slashdot" problem that 
> Morgaine outlined so clearly.
>
> The message flow assumes an avatar already present in some region, (a 
> small scale local home region in this case, but that is by no means 
> essential, it could be a build in region in the viewer or a big 
> commercial region). The user is preparing for a trip to immersive 
> world, and after some outfit adjustments moves over. 
>
> Finally i apologize for for the simplistic notation used here. I 
> simply add the most relevant parameters passed in square brackets to a 
> keyword specifying the nature of the message. Please improve on that 
> where needed.
>
> 0)  Viewer, here is an update of the state of the world your agent is 
> in, please render.
>     User: Hmm, amazing inventory has not been *that* amazing lately. 
> 'll make a backup, just in case
> 15) Hello immersive world, can i get in? Here are my credentials, and 
> a list of my stuff.
> 16) Asset service A, please send me a cap for X, here are my 
> credentials (I want this cap for consistency)
> 18) Asset service B, please send me a cap for Y, here are my 
> credentials (I want this cap for consistency)
> 20) Asset service B, please send me a cap for Z, here are my 
> credentials (I want a cap for consistency)
>      User thinks:  Crap! Big asset service does not allow  me to take 
> my yellow stockings! And Amazing assets  failed to deliver my zodiac 
> dress. At least i made a backup of that dress!
> 24) ... done ('ll trash them here and now, forever, who needs stuff 
> you can't use!)
> 25) The zodiac dress was not delivered by Big assets service, but i 
> have a local copy!
> 27) I dont know you, but I 'll trust you, here is the cap, but you 
> better store the data, its single use, i need to protect myself.
> 31) Cap was only good for one time, I made a copy, but my policy is to 
> only grant you fair use rights, at a later time i might even tell you 
> to replace the dress.
> 32) Viewer, you can wear Z for now, but the asset service granted only 
> fair use, i might ask you to replace the dress at a later time.
> 33) Ready at last! Off to immersive world!, I hope its not to crowded 
> there or 'll loose my dress...
> 34) Hello immersive world, here are my credentials, and a list of 
> stuff i want to bring
>    [Region service finds fair-use warning on Z and decides to make its 
> own copy]
> 41) Placement done, Z is currently buffered by us as wel, you need to 
> get details for X, have fun.
> 42) You are now in immersive world, your dress is buffered there as 
> well, but you need to get X!
> 45) Viewer, here is an update of the state of the world your agent is 
> in, please render.
>
> As far as I can see this conforms fully to our charter, and i hope it 
> is possible to use large portions of the existing code bases. However, 
> as said above, i did not really try to capture the old thinking, and I 
> also might have misconceptions about the way to do these things in 
> general.
> On Sun, Apr 3, 2011 at 8:38 PM, Vaughn Deluca <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Thanks for the pointers.  I have a  busy week in RL in front of
>     me, so i wont have to much time to respond the next few days,
>     however, i intend to start doing the following things:
>
>     - Produce a visual that reflects my thinking, i.e. an illustration
>     of my response to Morgaine's itemlist  above.
>     Regarding the use of domain, I think services are eventually what
>     counts, but its all terminology. The way I read the AWG diagrams
>     is that the agent domain is actually a cluster of tightly
>     integrated services. When the functionality of each sub-service is
>     described properly and with uniform interfaces the domain will
>     slowly dissolve. But let not get ahead of out selfs. We should put
>     up some clear descriptions on the wiki for our views on this, and
>     *after* that we can decide what we need and what can go.
>
>     Its been a very useful and illuminating weekend for me, and i am a
>     lot more optimistic about the future of vwrap than two weeks ago.
>
>     -- Vaughn
>
>
>
>     On Sun, Apr 3, 2011 at 7:20 PM, Dzonatas Sol <[email-masked]
>         Probably easy as suggested in other terms here on this list,
>         as how the client contacts the asset services now in the
>         regions. The newer issue is to unitize that asset services.
>         Since their is proprietary (legacy) code then we can't expect
>         that to change, and some form of proxy is of need. Whatever
>         Eventually, the agent domain is ideal to handle the direction
>         of the asset services. This concept, unfortunately, ended
>         support awhile ago with changes in LL.
>         (warn: unstructured collaborative notes, dumped on me and I
>         tried to fix)
>
>         I'd imagine the agent domain could grow out of unitized
>         versions of asset services. Despite that, I think that concept
>         helps view where we were at in discussion and what didn't happen.
>
>         Vaughn Deluca wrote:
>
>             Hi�Dzonatas
>
>                        > when designing for scalability, the model to
>             bear in
>                        mind is ...
>
>             keep in mind,
>             about how the
>             demands of that
>             slashdotted, so are
>             network traffic?
>             interest to the
>             fetches by the
>             already on region
>             nowhere to go in
>             services, we are
>             commercial asset
>             will rocket
>             want to host
>             every time we
>             happen anyway,
>             services refuse
>             handle a large
>             containing a host
>             other cases,
>             able to get it
>             <mailto:[email-masked]>>>
>
>                            � �>>
>             <mailto:[email-masked]>>>
>
>                            � �>

--

---

From: Carlo Wood <[email-masked]>
Date: Fri, 8 Apr 2011 22:34:02 +0200

This is very nice work and I think it clarifies a lot.

I have a few very basic questions.

I see that you request Z from two different Asset servers
(originally A, but also C when a backup has been stored there).

No matter how you look at it, that is distributed storage:
compare it with git or mercurial; if Z on A could be changed
then the backup would be out dated, and that is not what
we want. So, I conclude that 'Z' (or rather, then handle
used to refer to Z when asking for it) therefore refers to
a unmodifiable data (compare git's hex ID's that point to
a snapshot).

1) Is that correct?

If it is correct and the handle for Z used in messages
like "give me a cap for Z" refer to immutable data, then
the most logical thing to do would be to use a (large)
hash value of the data (ie, md5) or an UUID that was
generated when the data was last changed (which is less
good because it would cause duplicated data when something
is changed back to what it was before), or to use an
ID that is less large, but whose uniqueness would be
guaranteed by including a (for that authority unique) ID
of the authority that made the last change. The advantage
of the latter is less bandwidth (smaller ID's) and knowledge
of the authority right into the ID of something (handy
for routing). Disadvantages are: it suffers from the same
as the UUID in that it will duplicate data whenever the
same data is generated and it requires administration to
make sure that every authority has a unique ID (compare
giving people unique IP addresses).

2) Which of those is used? has, UUID or smaller specially
crafted ID?

3) What would happen if someone gets a cap for Z, a
modifiable object; then the object is modified and then
the cap is used? Does the cap have a guaranteed life time?

4) If not every previous state of an object is kept
eternally and after changing some object old caps (and
their static data) disappear - then how will the asset
servers that contain copies know that? They are not
necessarily aware that anything changed at all for
that object, so they can't know what the life time
is. It seems that once you make a copy you are doomed
to keep it forever or do garbage collection for assets
that are never accessed anymore.

5) I can image that at SOME TIME in the future we want
a few bit (or more) that ARE mutable-- despite that the
asset ID (Z) refers to snapshot (immutable) data.
Are we going to build into the protocol a provision for
such mutable bits?

This would mean, in the case that the ID is a hash (ie md5)
that the asset Data exists of a payload that the hash is
taken over plus a mutable part that is not considered for
the hash. Obviously, such data then could get desynced
between assets servers with copies.

---

From: Morgaine <[email-masked]>
Date: Sat, 9 Apr 2011 00:18:11 +0100

Excellent work, Vaughn!

You're right, I am working on something related to this, specifically a
design study for the Tourism use case.  It happens to end with a protocol
sequence diagram presented as a table of text, so I was very pleased to see
your highly relevant diagram.  Yours captures part of my use case, and it's
a lot prettier than my text format. :P

I was particularly impressed by the way you start off with completely
separable services right from the start.  Since separable services can be
put together under a single administrative domain very easily, whereas
separating conjoined services is not easy at all, I think you've started
this off perfectly for the VWRAP approach to services.

Because you have separated the services so well, your suggested protocol
flow could be said to to be targeting some kind of "*superset of all VWRAP
deployments*" deployment. :-)  Although it's logically structured, it's a
sort of worst-case scenario (or lawyer's delight) in which everyone has to
ask everyone else for permission to do anything, regardless of whether
permission is actually required or not.

That's viable, but less than optimal.  Specifically, you are working to the
principle of "The heaviest burden required by anyone must be borne by
everyone."  I have been trying to stick to the opposite principle of "A
burden should be borne only by those whose use case requires it", which is
both fairer and more efficient.

To illustrate this, consider the case of an asset service which serves (by
choice) only Creative Commons licensed assets --- an extremely important use
case which could well become the dominant one in an open metaverse of
community worlds.  Who knows, it could be operated by Debian, or Blender, or
OSgrid, or even Google Warehouse. :P

In such a scenario, because the license on all the assets in the asset
service permits unchecked distribution to all destinations in perpetuity,
the vast majority of all the request-grant protocol flows in your diagram
are superfluous when the assets come from this repository.  By using a
protocol which understands *WHEN* it needs to ask a question, a large amount
of cumulative round-trip time latency (and its resulting lag) can be avoided
entirely.  This is also true on a per-asset basis if an asset service serves
a mixture of encumbered and freely distributable assets, except that then
the difference would be seen per-asset instead of per asset service.

For such freely distributable assets, the agent service doesn't need to do
anything at all beyond recording the addresses of assets which are currently
being worn by the agent.  Since you start off your trip (sensibly) by
checking your clothing at home before you leave, you'll notice a broken
asset service locally anyway since your viewer will be trying to fetch it
for local viewing.  The agent service need do nothing at all, beyond record
the addresses of top level items.  (In my design study, I refer to a *Worn
Assets List *which is held by the user's agent service, and which is
entirely separate from any concept of inventory.)

Likewise, region services don't need to fetch the graphic assets normally
either (unless they opt to proxy them), but only pass the addresses of those
assets around to all the other agents in the corresponding region, so the
request-grant exchanges between regions and asset services can be avoided in
this case.  (Regions will be requesting other server-side data though, for
example the bounding box information or collision mesh of an asset, which
typically the viewer would not be fetching.)

That's not the end of the "*no unnecessary burden*" issue yet though,
because even if you removed all the unnecessary request-grant protocol
flows, you're still making the incorrect assumption that assets *ALL NEED TO
BE RESTRICTED* by the mere fact of asking for caps to everything.  This
itself is wrong.  The logic need to first determine whether a cap is needed
for fetching a given asset, and if it's not needed then the fetch can be
done by the viewer or region without this protocol burden at all.

So you see, there is a fundamental assumption in your nicely laid out flows
that all assets must be tied up in heavy red tape by the needs of the most
burdensome use case.  I don't agree with that, neither on principle nor on
engineering grounds.

Many of the flows you have shown are exactly what we need for securing
access to proprietary resources, but not all resources have that burden, and
I would want to elide a number of the flows away entirely when an asset
service allows it.

To put it another way, the data is king, and protocol flows should reflect
the requirements imposed by data, not the other way around.

I need this expressed in your flows, possibly as asset requirement
annotations.

PS.  Great work Vaughn, I think this gives us a wonderful launching point!

Morgaine.

======================

---

From: Morgaine <[email-masked]>
Date: Sat, 9 Apr 2011 02:11:00 +0100

Carlo, I too would like to hear what Vaughn had in mind in the areas you
mention, although it's perfectly possible that he was trying to keep the
issues of mutability and addressing out of the initial picture entirely,
just to keep things simple.  They are important issues though, and I'm glad
that you pointed them out.

Here I'll provide my views about this general area.

First of all, mutability breaks caching entirely, so it needs to be
approached with great caution.  Caching can make the difference between a
great service and a totally unusable one (or at least one that doesn't work
very well), so if mutability is allowed then things need to be designed in
such a way that caching still works *most of the time*, namely in between
mutations.

This is an issue which has occupied many minds for decades, and I think it
can be distilled into the widely accepted notion that cached objects should
never be overwritten, but only joined by updated versions.  At a stroke this
lets highly concurrent asset services avoid the thorny issue of writing in
the presence of concurrent readers, and at the same time it lets caches have
very simple update semantics since nothing is mutable from their
perspective.  The only cost is some loss of disk space to hold old versions,
which is rarely significant given disk sizes and costs today.

While that is good for asset services and caches, it does place the burden
of achieving mutability on the parties who require it.  And that of course
is how burdens should be borne.

What this means for virtual worlds is that a mutator becomes responsible for
notifying endpoints that something has mutated, so that they can fetch the
new versions.  This needn't be an onerous requirement, and it may not even
need to be wrapped up in security tape, since having had access once
probably qualifies you for an unconditional update.  In any case, the
original item is still in its asset service (as well as in users' terabyte
caches), so one very useful property of this approach is that a simulation
can't be broken for long by a poor update since reverting is always
possible.  That's a an engineering plus point.

In respect of addressing, you mentioned using hashes as item addresses, and
this is of course my preferred strategy, which I have described and
advocated several times this week, and back in September.  Hash-based
addressing has numerous excellent engineering properties that put it head
and shoulders above other schemes.  I say go with that approach.  In any
event, when we pit alternative schemes against each other on merit, I bet
nothing will come close to hash-based.

On the issue of caps, I think that keeping their semantics simple has great
merit, because heavyweight schemes are less likely to be accepted, and
complex ones are unlikely to be implemented uniformly.  But in any case, as
I described to Vaughn, caps should be *optional* anyway (ie. asset
dependent).  Having to acquire a cap in order to fetch a Creative Commons
licensed asset is unnecessary, and indeed it is rather comic.  A cap only
needs to be requested when the asset requires it, and only those assets that
need it should bear the burden.

The issue of flag bits (or more generally, property fields) for assets is
one that interests me a lot, as it relates to the above.  As I described to
Vaughn, it is the assets that impose requirements on the protocol, not vice
versa, so it is the assets that should carry the properties that control the
protocol.

Morgaine.

==============================

---

From: Carlo Wood <[email-masked]>
Date: Sat, 9 Apr 2011 03:58:37 +0200

On Sat, 9 Apr 2011 02:11:00 +0100
Morgaine <[email-masked]> wrote:

> approached with great caution.  Caching can make the difference
> between a great service and a totally unusable one (or at least one
> that doesn't work very well), so if mutability is allowed then things
> need to be designed in such a way that caching still works *most of
> the time*, namely in between mutations.

Yup, I totally agree. As you might know I've been working a lot
on improving the IRC protocol at the time. IRC works with handles
(nicks and channel names) and everything else is mutable (ie,
the channel topic, the channel modes, etc). This turned out to
be an unsolvable horror (and trust me on that please, I worked
7 years on this topic). What I did was change nick names into
numerics that are *unmutable*, so at least the bloody handle
wasn't changing all the time, heheh (channel names are already
unmutable) and then assigned authortities for the nick names
(namely those servers where the users are connected to). Authorities
have the nice property to have exclusively an outwards message
stream: from the authority away, and therefore for streamable:
if every mutating operation is kept in order than everything
remains synched in the end. This requires that one always ASKS
the authority to change something and not tell it that you
changed something. For example, I changed it that when you KICK
someone from a channel, then a request is sent to the server
where that person is connected to and that server actually
sends out the message that this user is removed from the channel.
Making an authority for channels was never done, there I have
tried to solve this problem with timestamps.

I don't think we should go this route (using time stamps).
Also, the authority "solution" has a the major disadvantage
that it only works in a non-cyclic routing tree; and and
as soon as any rerouting takes place you get into MAJOR problems
for messages that were still under way.

The ONLY way to really avoid all those nightmares is to adopt
how git and mercurial work: immutable data that some hash ID
refers to, which, as you said is, "never" deleted.

> This is an issue which has occupied many minds for decades, and I
> think it can be distilled into the widely accepted notion that cached
> objects should never be overwritten, but only joined by updated
> versions.  At a stroke this lets highly concurrent asset services
> avoid the thorny issue of writing in the presence of concurrent
> readers, and at the same time it lets caches have very simple update
> semantics since nothing is mutable from their perspective.  The only
> cost is some loss of disk space to hold old versions, which is rarely
> significant given disk sizes and costs today.

You totally convinced me :). And for the others: note that I tried
it in other ways for YEARS. So, it means something that now I'm 
convinced that wasn't right and we should avoid it.

> While that is good for asset services and caches, it does place the
> burden of achieving mutability on the parties who require it.  And
> that of course is how burdens should be borne.

Also very true.

> What this means for virtual worlds is that a mutator becomes
> responsible for notifying endpoints that something has mutated, so
> that they can fetch the new versions.

This sound like an 'authority' however: one entity and one alone
can issue the out going message that something has changed...
That is not how it should work though. I can't wrap my finger
around the difference yet though :/... If we go for immutability
then why suddenly are we talking about having to notify others
that something changed?

Of course, things DO change in-world. For example, someone could
detach something - and attach something else. Then the Agent of
that avatar is the authority I'd think: the viewer requests the
Agent to make a change, and if approved then the Agent tells the
viewer and everyone else that the change was made.

I guess that the big difference is that in those outgoing messages
is no large 'data'.. no ASSET data.  The Asset servers themselves
would never do this. Only work-tied (location tied) things will do
this: avatars and rezzed objects, with respectively the Agent
and the Region as authority/source of the mutating messages.

Routing probably goes all through the Region server: if someone
changes an attachment while they are 4000 meter away (in the same
sim) then that STILL has to be routed to everyone else in the sim,
and not later. Basically at least, the Agent *tells* the Region
server that the avatars appears has changed and the Region sends
outward messages of that fact to everyone who is connected.

As long as all mutating messages go in one direction: away from
the authority (the Agent in this case) and there are no RE-routing
issues (which is not the case here) then there are no problems
with this model.

>  This needn't be an onerous
> requirement, and it may not even need to be wrapped up in security
> tape, since having had access once probably qualifies you for an
> unconditional update.  In any case, the original item is still in its
> asset service (as well as in users' terabyte caches), so one very
> useful property of this approach is that a simulation can't be broken
> for long by a poor update since reverting is always possible.  That's
> a an engineering plus point.

If all things are well, then the outgoing 'mutation' message from
the Agent/Region only contains new asset ID's, not the data itself.
And people will get the new data using the new ID.

This sound perfectly ok for textures (which aren't even mutatable
in-world), but what about a little change to the shape of a prim
of an object?  An object (existing of many prims) is an asset:
you can get store it in an asset server and later retrieve it
again.  Hence, we have to realize that such objects are NOT
mutable. Only once they are rezzed they are mutable. This is a
requirement for things to work. A rezzed object is therefore
not an asset: it's world-data that can change (with the Region
as authority? or the owner/viewer maybe, when they are online).
Only once an object is taken back into inventory is the data
send to an asset server and a new ID is created. Until that point
all the data for such objects is exclusively stored in the region
and people obtain the data for the shape of objects (not the textures,
but for which texture ID is used on what face) from the region,
not from an asset server.

This follows from the mutablity argument (not from the fact that
this how it works in SL too).

> In respect of addressing, you mentioned using hashes as item
> addresses, and this is of course my preferred strategy, which I have
> described and advocated several times this week, and back in
> September.  Hash-based addressing has numerous excellent engineering
> properties that put it head and shoulders above other schemes.  I say
> go with that approach.  In any event, when we pit alternative schemes
> against each other on merit, I bet nothing will come close to
> hash-based.

I can't think of any disadvantages. The hash has to have a large size
of course, comparable to UUID's. Still,I'm willing to assume that
with a lot of effort it would be possible to create an asset with
a given hash that in fact is different... Would that be a problem?

Once you know the data, you can reconstruct the item anyway. You
also know the ID (hash or not). You can only know the hash if you
already know the data anyway, or when you have access to it (of course).
Being able to then create an asset that has the same hash, but in
fact is white noise (I definitely can't think of any other way
to construct a known hash) should simply result in the white noise
being discarded: someone "uploads" data that has an already existing
hash, then discard the uploaded data and use the old data. The result
is the uploader/hacker didn't gain anything at all.
 
> On the issue of caps, I think that keeping their semantics simple has
> great merit, because heavyweight schemes are less likely to be
> accepted, and complex ones are unlikely to be implemented uniformly.
> But in any case, as I described to Vaughn, caps should be *optional*
> anyway (ie. asset dependent).  Having to acquire a cap in order to
> fetch a Creative Commons licensed asset is unnecessary, and indeed it
> is rather comic.  A cap only needs to be requested when the asset
> requires it, and only those assets that need it should bear the
> burden.

Hear hear! I like this idea very much :).
But it is unrelated to the ID / unmutable data of course.
This is just about how easy it is to get a cap for something.
I guess that what you mean is that a free asset should have a
cap that exists of it's hash. So that if you know the ID/hash
(ie 'Z') you know immediately where to get it.

> The issue of flag bits (or more generally, property fields) for
> assets is one that interests me a lot, as it relates to the above.
> As I described to Vaughn, it is the assets that impose requirements
> on the protocol, not vice versa, so it is the assets that should
> carry the properties that control the protocol.

I've often desired mutable bit in no-modify objects in SL.
There are numerous applications for it! The idea is that
you have a no modify object but as owner still can change
certain bits that define how it is used AND that are
stored when you take it back into your inventory (are preserved
when next time you rez it again). However, 'no modify' and
the immutability that we talked about are different things
of course! If we assume that such bits are simple changes
to the object that are allowed by the owner at all times,
then the only disadvantage is that (apparently) all data
of the object needs to be stored multiple times: if their
are 4 bits and the users "plays" with them until they had
all 16 possibilities once in their inventory then we'd have
16 times the same data in the asset server.

This however is just a way to look at it (compare with
the way how we look at how a git server works: that view
is highly inefficient too, though easy to grasp).

The real implementation can of course make it so that it
doesn't store that data 16 times...

---

From: Morgaine <[email-masked]>
Date: Sat, 9 Apr 2011 04:29:03 +0100

I agree with virtually everything you've written here, Carlo.

(And your observations about how this even applied to your experience with
IRC were interesting too, and unexpected.)

I'll just add a couple of small decorations.

First, on the issue of  "authorities" that control mutation, there is
another way of looking at this, a way which any practitioner of Functional
Programming would find very natural:  a "mutating" object can be thought of
as an infinite sequence of immutable timestamped object states.  And while
traditional imperative computing tends to consider FP as "odd", there is
nothing at all odd about an incoming stream of events.  There's your
"mutation authority" for you --- it's merely the event stream generator,
each event being immutable. :P  This fits in perfectly with event-driven
programming of course.

The second point I'd like to make refers to your section about assets versus
objects.  As you say, there is a distinction to be made, and the semantic
gap seems to open very wide between them when objects are changing rapidly.

However, there is also an important way in which the two are related, which
again could be considered the "FP viewpoint".  Assets are really just
immutable *STATES* of an object.  In SL and in Opensim currently, assets
provide the *initial* state of an object when it is brought into a region
(rezzing), and new assets can subsequently be *generated* from it by taking
a snapshot of the live object ("Take Copy"), or by saving the object on
finally removing it from the world (derezzing).  The "asset as an immutable
object state" paradigm is very easy to see.

All this seems to fit together rather nicely, and since it is the model that
underlies Second Life, I think Linden Lab deserve kudos for a core data
model that makes sense both conceptually and also for practical
cacheability.  Of course one can't just rest there, but it's a good starting
place. :-)

Going beyond where we are currently, the ability of active objects to
deliver events to viewers is extremely weak in our current model, with an
almost total lack of usable communications other than via repurposed chat
streams.

Other open world systems have a much stronger object communication model.
For example objects in OpenWonderLand have two parts, one in-world and one
in-client, and these two halves can talk to each other directly to implement
any arbitrary complex behavior.  And in OpenCobalt, although there are no
"servers" in the peer-to-peer implementation of islands (but there are
"router" hosts), the states of the fully programmable objects in one
client's scenegraph automatically propagate to the scenegraphs in all other
clients present.  So again, there is a very powerful model of interaction
between participants.

Although we haven't placed object communications  within our scope, if VWRAP
succeeds then one day someone will need to extend it to region-client and
inter-VW object communications as well.

Morgaine.

=======================

---

From: "Patnad Babii" <[email-masked]>
Date: Sat, 9 Apr 2011 05:38:23 -0400

While reading through this email, I've got an idea, that i don't think we 
spoke about before but I really think it could become handy.

We have to allow some kind of synchronisation to take place on some assets.

Let me describe you the use case i see where it fits.

I make a vendor's server lets say, that i'm going to use on GRID A and GRID 
B.

I don't visit GRID B very often, but on the other hand i'm connecting on 
GRID A alot.

I do some modification on my server's code in GRID A and I'd like the GRID B 
to have the exact same modifications without having to log there and start 
to code again.

So, what would be really useful is if in a way I could say to GRID B to 
refresh my server without having to log in there.

That's it, that was my idea, not sure it fits right here right now, but 
might be to take in consideration  while designing the protocol.

Thanks

-----Message d'origine----- 
From: Carlo Wood
Sent: Friday, April 08, 2011 9:58 PM
To: [email-masked]
Subject: Re: [vwrap] Is 'Data Z' immutable (like a git snapshot)?

Also very true.

---

From: Morgaine <[email-masked]>
Date: Sat, 9 Apr 2011 17:05:50 +0100

Patnad, if you mean synchronized updates of objects, then yes, this is what
Carlo and I were discussing in the emails of this thread.  That's the
"mutability" of an object to which we were referring.

However, it shouldn't happen through actual mutation of an asset in the
asset services (in our view), because as we discussed earlier, this would
have bad consequences for the cacheability of assets, it would complicate
asset services and make them less concurrently scalable, and there would be
no means of fault isolation when an update delivers bad data and propagates
to everyone automatically.

Instead, we were envisaging all assets in asset services being completely
immutable, always.  Then an "update" would consist of adding another newer
asset to the asset service, and signaling that an update exists only to the
desired endpoints.  This would allow control over the breadth of update
effect, since endpoints that are not notified would not automatically sync
up, so you can select your own target set for your update trial.

Although we haven't discussed the following mechanism yet, the way I
envisage updates being propagated is through an optional subscription path
in the protocol, which has the merit that the burden of updateability rests
only on those assets that require it, and not on all assets.  I mentioned
"property fields" (ie. bits or flags) in a response to Carlo yestereday, and
this is one place where the notion of "asset properties" can be put to good
use.

If an asset is marked as being "*Updateable*" through a property bit, it is
still entirely immutable in asset services and remains valid in all caches.
However, at the point where a client (or a region server in the case of a
bounding-box / collision mesh asset) receives the asset, when it notices the
"*Updateable*" property bit on the asset then it has the option of availing
itself of the update when it becomes available.

The way this would work in my subscription-based approach is very simple.
On noticing the *Updateable*" bit being set in an attribute for asset A, the
receiving endpoint E would send off a protocol message which says "*This
endpoint E wishes to subscribe to notifications for updates on asset A*",
which would be a protocol message type defined in our protocol.  Notice that
this makes the update process "*opt-in*", which is a very desirable trait
especially in regards to privacy and security.

But where would the recipient endpoint send this message?  I propose that
specifying the target should be kept flexible and extensible by placing that
information in yet another asset, which the asset service can give the
recipient upon request.  This can work as follows, although there are many
possible variations on this theme:

The party that offers updateability of asset A also stores an "*UpdateInfo*"
asset in the same asset service, a tuple structured like this:

*UpdateInfo:{A, UpdateSubscriptionURI, Description}*

When the asset service receives this *UpdateInfo* asset, it creates a local
binding between asset A and the URI of this* *UpdateInfo asset, such that if
an endpoint subsequently requests *fetchUpdateInfo(A)* then the URI of the
UpdateInfo asset is returned.  The requester can then use that URI to fetch
the UpdateInfo asset using the standard asset fetch mechanism, and can then
use the URI held in the received *UpdateSubscriptionURI* field to send a
subscription request to the party offering updates.

There are many possible variations on this idea, but the key to flexibility
is holding the update information in a new asset.  This introduces many
benefits:

   - Ordinary assets do not carry the burden of any update machinery.
   - Updateable assets that the user does not wish to update do not carry
   the burden of any update machinery either (the "*Updateable*" property is
   just ignored at the time the asset is received).
   - If a recipient that did not initially subscribe to updates changes its
   mind later, nothing is lost, because the update contact information is
   securely stored in the asset service and can be requested at any time.
   - It also allows endpoints to choose not to subscribe to updates at the
   time of asset receipt but as a scheduled background activity instead.
   - Asset services can continue to do what they do best, namely just stream
   immutable assets at blue light speeds.  The separate binding service (a
   simple hashed lookup keyed on the same asset address as normal asset
   fetches) is a side facility, and doesn't impact on the asset service at all.
   - The update mechanism is opt-in, which is a benefit for privacy and
   security.
   - The party offering the update can easily store a new *UpdateInfo* asset
   if the *UpdateSubscriptionURI* changes, which the asset service can
   either use to replace its previous binding, or else just add it to a list of
   *UpdateInfo* offers.
   - The *UpdateInfo* assets themselves are immutably stored in the asset
   service, so the bindings are recoverable even if lost.
   - Caching works normally for all assets, even the updateable ones.
   - The updater retains full control over to whom to offer updates out of
   the opt-ins, and can reduce the set of endpoints updated to suit its policy
   or resources.
   - The *UpdateInfo* assets don't even need to be stored in the same asset
   service as the assets to which they are bound.  It's perfectly possible to
   have asset sites dedicated to update notifications alone.  This would
   require clients to have knowledge of such sites so that they request update
   notifications to them instead of to the original asset services, but it's
   not particularly hard.

How updates are actually offered later, once they become available, is a
separate issue.  The above just handles subscribing to notifications about
updates.  It's pretty easy to see how the circle could be made complete
though --- the updater notifies opt-ins that an update is available, upon
which they can fetch the new asset from an asset service and save it as an
asset replacement in their cache.

How the notification is sent by the updater should be flexible.  I have
implied that the user's agent service is online and so direct notification
is possible, as this will probably become much more common tomorrow under
IPv6 which does not hide clients behind NAT.  Other means by which updaters
can send update notifications should be provided too though.  Alternatively,
regions could subscribe to be notified of updates to client assets, and when
the region is sending the asset URIs to its attached clients, it could pass
any notifications about updates along to these clients too.  Giving regions
more work is not a very good idea though.

There are lots of possible alternatives in this area.  I've described only
one or two.

Morgaine.

On Sat, Apr 9, 2011 at 10:38 AM, Patnad Babii <[email-masked]> wrote:

> I do some modification on my server's code in GRID A and I'd like the GRID
> B to have the exact same modifications without having to log there and start
> to code again.
>
> -----Message d'origine----- From: Carlo Wood

---

From: Vaughn Deluca <[email-masked]>
Date: Sat, 9 Apr 2011 23:20:10 +0200

Carlo, Morgaine,
Here are some anwers to your questions. I skipped some points stuff
that i don't really feel qualified to answer.

>'Z' (or rather, then handle used to refer to Z when asking
>for it) therefore refers to a unmodifiable data
>1) Is that correct?

Very good question, its clear the answer should be yes, or we end
up with big problems, (as has been detailed in the meantime in the
exchange between  you and Morgaine. When i made the example i indeed
tacitly assumed the data was immutable. A agree that the way SL is doing
this now will be a good start. We have trouble enough as it is.

Regarding your question 2 about hash vs. special ID, I leave
that to the experts to contemplate, and answer. I just would
like to say that when a bandwith argument is used, the complete
transaction should be considered, there is no point in optimising
the first phase, if in the final exchange  orders of magnitude
larger blocks of data are send, swamping small bandwidth
differences created at relative hight coasts (in term of design complexity).
But in cases were only a small amount  of metadata
is exchanged it could have an impact, -however, i doubt it.

>the cap is used? Does the cap have a guaranteed life time?

I assumed existing REST-full methodology would
have provisions  to communicate the lifetime and restrictions of the cap.
I explicitly used that in my examples (one-time cap and
fair use resctictions) If such mechanisms are not standard practise
(what i would find surprising) i think we should define them.

>servers that contain copies know that?

See above for the mutability and lifetime issues. Regarding
storage times of objects, Its up to the asset server to decide
what caps it gives out, if those are supposed to work eternally
the data should be kept eternally by a quality service. Garbage
collection rules can be advertised upfront, so users can decide what
service type fits there needs, and be prepared to find there stuff
evaporated if they  opted for a minimal service...

>5) [...]Are we going to build into the protocol a provision for
>such mutable bits?

I would say no. Not that i dislike  the idea, but I wonder if that is a
VWRAP issue or something that could be delegated to lower levels. Certain
object types could have this mutability property in spite of a fixed ID,
but
at the protocol level its still an object like all others. Or not?

--Vaughn

On Sat, Apr 9, 2011 at 3:11 AM, Morgaine <[email-masked]>wrote:

> What this means for virtual worlds is that a mutator becomes responsible
> for notifying endpoints that something has mutated, so that they can fetch
> the new versions.  This needn't be an onerous requirement, and it may not
> even need to be wrapped up in security tape, since having had access once

---

From: Vaughn Deluca <[email-masked]>
Date: Sat, 9 Apr 2011 23:31:20 +0200

Morgaine,

Thanks for the compliments and the extensive comments  :)
I am in a time crunch, so i will only respond to one aspect of your mail,
and come back to some other points later.

I am not sure i understand your emphasis on the (non)transfer of trust info
to gain speed. When drafting the diagram I was thinking that depending on
the  "domain" of the sender of the message  (with domain defined in the
classical sense of a range of IP addresses) the authorisation info might
 simply be dropped and the data used without further checking if the
receiver wishes to do so. Also since in the majority of cases only caps are
passed that contain *implicit* trust. The checking of the validity of the
cap is local to the service, and should be really fast.

Regarding capabilities, i was viewing them not so much as credentials
(although they are) but more
as a convenient way to pass references to some bit of underlaying data
around. You can't  eliminate those messages even when not checking
credentials. The roundtrips are anyhow needed to make sure that the
communication is actually working. Or can we really get away with an UDP
style of send and pray?? I fail to see how you would be able to realise a
substantial gain over what will be needed anyhow as bare bone infrastructure
and for error checking/reporting.  But i might be wrong.

One way way to find out is to implement it, and I feel that we are getting
closer to be able to do just that.

-- Vaughn

On Sat, Apr 9, 2011 at 1:18 AM, Morgaine <[email-masked]>wrote:

> protocol which understands *WHEN* it needs to ask a question, a large
> amount of cumulative round-trip time latency (and its resulting lag) can be
> avoided entirely.  This is also true on a per-asset basis if an asset
> service serves a mixture of encumbered and freely distributable assets,
> except that then the difference would be seen per-asset instead of per asset
> service.
>
> flows, you're still making the incorrect assumption that assets *ALL NEED
> TO BE RESTRICTED* by the mere fact of asking for caps to everything.  This
>> - Illustrate consistency problems along the lines discussed  here higher
>> up in this tread, as well as the "slashdot" problem that Morgaine outlined
>> so clearly.
>>
>> essential, it could be a build in region in the viewer or a big commercial
>> region). The user is preparing for a trip to immersive world, and after some
>> outfit adjustments moves over.
>>
>> Finally i apologize for for the simplistic notation used here. I simply
>> add the most relevant parameters passed in square brackets to a keyword
>> 16) Asset service A, please send me a cap for X, here are my credentials
>> (I want this cap for consistency)
>> 18) Asset service B, please send me a cap for Y, here are my credentials
>> (I want this cap for consistency)
>> 20) Asset service B, please send me a cap for Z, here are my credentials
>> (I want a cap for consistency)
>> only grant you fair use rights, at a later time i might even tell you to
>> replace the dress.
>>>> asset services. Despite that, I think that concept helps view where we were
>>>> at in discussion and what didn't happen.
>>>>
>>>> Vaughn Deluca wrote:
>>>>
>>>>> Hi�Dzonatas
>>>>>

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 09 Apr 2011 18:27:28 -0700

Forwarded to vwrap-list:

Dzonatas Sol wrote:
> Just thought about this a little more...
>
> I think with your first VD1 that only thing that really needs to be 
> added is to add space between the local and external area to fit in 
> the resource name per arrow. That way the public resource name is 
> specified. Then instead of those request for cap transitions, these 
> would be implied by those resource names. Above each line of each 
> arrow, just add the appropriate public resource name there. We can 
> deal with private resources later, as those are already implied, too.
>
> This group never did create any dictionary of resource names. They 
> only exist in viewer source and in SNOW-375.
>
> I don't know if I can modify the PDF to make an example of above.
>
> Dzonatas Sol wrote:
>> Perhaps, that would be best to reflect upon the past.
>>
>> There have been talks to split out the renderer from the viewer, yet 
>> the render depends on some of the network. To call that the local 
>> region is appropriate as you have. The renderer/network-loop does the 
>> bulk of the work now that others think the simulator does. That's 
>> where we get hung up on local sim or external sim, and components.
>>
>> Maybe easier not to worry about requests for caps for now and keep 
>> the way your going. We can come back later and describe how the 
>> connections/ReSTful patterns work later. Please just indicate it's 
>> the above ReSTful view of the flow (higher-level) and us 
>> implementators will comprehend.
>>
>> =)
>>
>> Vaughn Deluca wrote:
>>> Dzonatas Sol
>>> >Then again, split the viewer out for local agent services and maybe 
>>> it will appear trivial.
>>>
>>> Right,  Maybe we should consider  *only* the viewer as local, and 
>>> assume all other services are external, just to make the example clear.
>>> Thanks for the other feedback, I will look at the snow-375 example.
>>> --Vaughn
>>>
>>> On Fri, Apr 8, 2011 at 9:00 PM, Dzonatas Sol <[email-masked] 
>>>     definition. Not that you did anything wrong, it just something
>>>     that happens more at the transfer layer from ReST and lower. All
>>>     the arrows you have that go from the Local to External let's
>>>     consider those "forward flow" and those that from from external to
>>>     local as "reverse flow." This becomes more obvious for reasons why
>>>     when firewalls and proxies are in the way and connections may need
>>>     to exist in opposite of the flow. Between unidirectional and
>>>     bidirectional flows is were this discussion digresses to vanilla
>>>     HTTP/caps and not fully ReSTful as desired.
>>>
>>>     I think you already see the higher-level request to begin
>>>     capability, end capability, and determine if it needs to request
>>>     capabilities. With bidirectional resources, there are less
>>>     requests for capabilities and mainly need for digests of
>>>     capabilities that begin and end. With unidirectional resources,
>>>     there are needs to request capabilities, that (currently on
>>>     servers) begin as private capabilities. Also with unidirectional
>>>     resources, there are keep-alives and long-poll requirements on the
>>>     resources, which isn't mandatory on bidirectional resources.
>>>     Bidirectional resources can use more ReSTful credentials, so there
>>>     would be no need to request capabilities (only need to know they
>>>     I imagine two big polygons around the Local and External areas on
>>>     the diagrams, yet to further image the arrows on actual flow might
>>>     not be so trivial as the desired flow noted. Then again, split the
>>>     viewer out for local agent services and maybe it will appear 
>>> trivial.
>>>
>>>     Vaughn Deluca wrote:
>>>
>>>         The main reason that i am submitting this in spite of my lack
>>>         of formal expertise is that the group in my view badly needs a
>>>         solid basis for discussion and preventing endless repeating
>>>         loops. This example is probably wrong in many ways, but its
>>>         better than what we have publicly available on interop now
>>>         (although Morgaine is working on something along the lines of
>>>         I hope this diagram will give us a base for discussion. I
>>>         could have done my homework better by researching the old OGP
>>>         stuff in more depth, and i probably  will do so in the future
>>>         , but for now I just tried to followed the general principles
>>>         as far as i understand them, to see what response that yields
>>>         from the group. In other words,I try to let the group educate
>>>         me :p
>>>
>>>         Note that in  my view all services are equal, in principle it
>>>         does not matter in what "domain" they run, since trust and
>>>         policy are fully localized. It is however very possible to
>>>         have internal shortcuts in the services to speed up processing.
>>>         In the example I opted for an external Agent service, but I
>>>         could as well have incorporated that in the set of local
>>>         services. As indicated above all services could also be run by
>>>         different organisations, true to what VWRAP stands for. Its
>>>         all up to the deployer, including a user at home who might
>>>         want to run a full world for family and friends. Those friends
>>>         might try to use that agent service to venture out in the
>>>         virtual universe. I envision that the final identity  provider
>>>         is external, using OpenID and OAut  or whatever other  magic
>>>         that I do not yet fully understand exists out there.
>>>
>>>         -  Provide a reference for discussion - Illustrates the use
>>>         case of tourism, and *true* interop.
>>>         - Illustrate consistency problems along the lines discussed
>>>          here higher up in this tread, as well as the "slashdot"
>>>         problem that Morgaine outlined so clearly.
>>>
>>>         The message flow assumes an avatar already present in some
>>>         region, (a small scale local home region in this case, but
>>>         that is by no means essential, it could be a build in region
>>>         in the viewer or a big commercial region). The user is
>>>         preparing for a trip to immersive world, and after some outfit
>>>         adjustments moves over.
>>>         Finally i apologize for for the simplistic notation used here.
>>>         I simply add the most relevant parameters passed in square
>>>         brackets to a keyword specifying the nature of the message.
>>>         Please improve on that where needed.
>>>
>>>         0)  Viewer, here is an update of the state of the world your
>>>         agent is in, please render.
>>>         1)  Agent service, I will go in my Zodiac dress that i keep in
>>>         the  "Amazing assets" service.
>>>            User: Hmm, amazing inventory has not been *that* amazing
>>>         lately. 'll make a backup, just in case
>>>         9)  Hello asset service A, please send me a cap for Z, here
>>>         are my credentials
>>>         14) Viewer, Z is now stored for you     User: I am Ready!,
>>>         Lets try to get to immersive world!
>>>         15) Hello immersive world, can i get in? Here are my
>>>         credentials, and a list of my stuff.
>>>         [Region service: Timeout... amazing inventory must be
>>>         overloaded.. oh well... ]
>>>         21) Agent service, you wanted to send somebody over, here are
>>>         your permissions.
>>>             User thinks:  Crap! Big asset service does not allow  me
>>>         to take my yellow stockings! And Amazing assets  failed to
>>>         deliver my zodiac dress. At least i made a backup of that 
>>> dress!
>>>         24) ... done ('ll trash them here and now, forever, who needs
>>>         stuff you can't use!)
>>>         25) The zodiac dress was not delivered by Big assets service,
>>>         but i have a local copy!
>>>         27) I dont know you, but I 'll trust you, here is the cap, but
>>>         you better store the data, its single use, i need to protect
>>>         myself.
>>>         31) Cap was only good for one time, I made a copy, but my
>>>         policy is to only grant you fair use rights, at a later time i
>>>         might even tell you to replace the dress.
>>>         32) Viewer, you can wear Z for now, but the asset service
>>>         granted only fair use, i might ask you to replace the dress at
>>>         a later time.
>>>         33) Ready at last! Off to immersive world!, I hope its not to
>>>         crowded there or 'll loose my dress...
>>>         34) Hello immersive world, here are my credentials, and a list
>>>         of stuff i want to bring
>>>         35) Hello asset service A, please send me a cap for X, here
>>>         are my credentials     [darn, I should have kept that cap from
>>>         last time..]
>>>           [Region service finds fair-use warning on Z and decides to
>>>         make its own copy]
>>>           [Region service stores asset in private storage, providing a
>>>         cap to replace the fair use one]
>>>         39) Agent service, you wanted to send somebody over, here are
>>>         your permissions & info.
>>>         41) Placement done, Z is currently buffered by us as wel, you
>>>         need to get details for X, have fun.
>>>         42) You are now in immersive world, your dress is buffered
>>>         there as well, but you need to get X!
>>>         45) Viewer, here is an update of the state of the world your
>>>         agent is in, please render.
>>>
>>>         As far as I can see this conforms fully to our charter, and i
>>>         hope it is possible to use large portions of the existing code
>>>         bases. However, as said above, i did not really try to capture
>>>         the old thinking, and I also might have misconceptions about
>>>         the way to do these things in general.
>>>         On Sun, Apr 3, 2011 at 8:38 PM, Vaughn Deluca
>>>         <[email-masked] <mailto:[email-masked]>
>>>         <mailto:[email-masked]>>> wrote:
>>>
>>>            - Read up on the older notes, as well as  more reading in
>>>         the list
>>>            archive
>>>            On Sun, Apr 3, 2011 at 7:20 PM, Dzonatas Sol
>>>                    <mailto:[email-masked]
>>>         <mailto:[email-masked]> <mailto:[email-masked]
>>>         <mailto:[email-masked]>>>>
>>>
>>>                    wrote:
>>>
>>>                       Some stated the proxy-to-asset-server is built
>>>         into the
>>>                    sim;
>>>                       however, keep in mind possible legacy support
>>>         where the
>>>                    asset
>>>                           Somehow I feel the basic asset server being
>>>         able to
>>>                    login and
>>>                               and many different use cases. One 
>>> particular
>>>                    use case to
>>>                               keep in mind is: "User acquires new
>>>         outfit, and
>>>                    wants to
>>>                               model affects the ability to host 
>>> personal
>>>                    asset services.
>>>
>>>                               Granted the collection of services 
>>> that are
>>>                    provided by
>>>                               Well... who said the same CPU's have 
>>> to do
>>>                    proxying,
>>>                               proxying is a different service than 
>>> physics
>>>                    simulation
>>>                               deployment patterns, the same caching
>>>         services
>>>                    could be
>>>                               > I think you're wrong that it has to
>>>         cost much
>>>                    money. ?vs?
>>>                               > It costs money to host a high
>>>         performance and
>>>                    scalable
>>>                               asset service and a high bandwidth
>>>         network to
>>>                    handle the
>>>                               I think what you're saying is: "It costs
>>>         a lot
>>>                    of money to
>>>         assets
>>>                    are spread
>>>                               throughout the internet they don't have
>>>         to be
>>>                    scalable."
>>>                               But that's not quite right. You're
>>>         opening up
>>>                    every asset
>>>                               It's the exact opposite of your
>>>         intention, but
>>>                    I think
>>>                               wishes to build a region that supports a
>>>         small
>>>                    population,
>>>                               can do so economically. A region that
>>>         wants to
>>>                    host a
>>>                               *large* population has to bear that 
>>> cost of
>>>                    providing that
>>>                               scalable asset service.
>>>                               I want the economics of hosting a small
>>>         asset
>>>                    service to
>>>                               shouldn't have to pay money just to
>>>         create or
>>>                    own VW
>>>                                   Izzy, when designing for
>>>         scalability, the
>>>                    model to
>>>         assets
>>>                    from many
>>>                                   different worlds, those assets being
>>>         served
>>>                    by many
>>>                                   different asset services. �Both
>>>         worlds and
>>>                    asset
>>>                                   personal services, and as the 
>>> metaverse
>>>                    grows, that
>>>                                   When those seasoned travelers click
>>>         on an
>>>                    advertised
>>>                                   VW link and perform an inter-world
>>>         teleport
>>>                    to one
>>>                                   region) will contain references to 
>>> asset
>>>                    services
>>>                                   travelers' clients occur over many
>>>         parallel
>>>                    paths from
>>>                    out over
>>>                                   This is very different to the case 
>>> of a
>>>                    proxying
>>>                    asset worn
>>>                                   by every avatar present. �In our 
>>> current
>>>                    architecture,
>>>                                   scripting, and absolutely cannot
>>>         afford to
>>>                    serve
>>>                                   that direction at all beyond
>>>         improving the
>>>                    code like
>>>                                   This is why we have to go parallel,
>>>         and I
>>>                    think you're
>>>                                   wrong that it has to cost much
>>>         money. �As
>>>                    we spread
>>>                                   already out there on the Internet,
>>>         at least
>>>                    in respect
>>>                                   of community and private 
>>> resources. �But
>>>                    add to the
>>>                                   opportunity, and not only will the
>>>         number
>>>                    of asset
>>>                                   too, because, after all, these
>>>         businesses
>>>                    will be
>>>                                   implementation, that's an easy 
>>> question.
>>>                    �It costs
>>>                                   service and a high bandwidth 
>>> network to
>>>                    handle the
>>>                                   traffic. �A *lot* of money. �In
>>>         contrast,
>>>                    it costs a
>>>                                   � �> As always though, it's a 
>>> trade-off,
>>>                    since the
>>>                                   proxied design
>>>                                   � �I don't agree with that... If a 
>>> user
>>>                    enters a
>>>                                   highly populated
>>>                                   � �region,
>>>                                   � �every other client is going to 
>>> (could
>>>                    and should be
>>>                                   trying to)
>>>                                   � �hit the
>>>                                   � �asset server(s) for the assets
>>>         that the
>>>                    user is
>>>                                   wearing (assuming
>>>                                   � �they're not cached locally). 
>>> �Every
>>>                    asset server
>>>                                   has to be scaled up
>>>                                   � �to the point that it can handle 
>>> that
>>>                    load from all
>>>                                   over...
>>>
>>>                                   � �demand. If the region is 
>>> proxying the
>>>                    assets, then,
>>>                                   yes the
>>>                                   � �region has
>>>         demand
>>>                    too, but it
>>>                                   � �scaled to meet other demands of
>>>         being a
>>>                    region
>>>                                   server... and why is
>>>                                   � �scaling those asset proxy
>>>         services hard?
>>>                    �It's
>>>                                   going to cost $,
>>>                                   � �but is
>>>                                   � �that... sure it will cost me, 
>>> but the
>>>                    simulation
>>>                                   will be consistent
>>>                                   � �and users will be able to 
>>> participate
>>>                    equally,
>>>                                   regardless of the
>>>                                   � �capabilities of their individual
>>>         asset
>>>                    services.
>>>
>>>
>>>
>>>
>>>                                   � �> inform its users about the
>>>         downsides
>>>                    of all the
>>>                                   trade-offs we
>>>                                   � �have made,
>>>                                   � �> The specific trade-off that 
>>> you are
>>>                    discussing is no
>>>                                   � �different. �A region
>>>                                   � �> asset servers over the items 
>>> in the
>>>                    region, so
>>>                                   that it can
>>>                                   � �ensure that
>>>                                   � �> as everyone else. �That does 
>>> indeed
>>>                    provide a
>>>                                   greater guarantee of
>>>                                   � �> consistency than a deployment
>>>         in which
>>>                    the region
>>>                                   only passes
>>>                                   � �asset URIs to
>>>                                   � �> clients who then fetch the
>>>         items from
>>>                    asset services
>>>                                   � �> though, it's a trade-off, 
>>> since the
>>>                    proxied
>>>                                   design has very
>>>                                   � �poor scalability
>>>                                   � �> If we're going to warn users 
>>> of the
>>>                    potential for
>>>                                   inconsistency
>>>                                   � �in the
>>>                                   � �> distributed deployment as you
>>>         suggest,
>>>                    are we
>>>                                   also going to
>>>                                   � �warn them of
>>>                                   � �> non-scalability in the proxied
>>>         one? �I
>>>                    really
>>>                                   don't see much
>>>                                   � �merit in the
>>>                                   � �> idea of warning about design
>>>         choices.
>>>                    �Many such
>>>                                   choices are
>>>                                   � �technical, and
>>>                                   � �> the issues are quite likely to
>>>         be of
>>>                    little
>>>                                   interest to
>>>                                   � �non-technical users
>>>                                   � �> You mentioned users "voting
>>>         with their
>>>                    feet" or
>>>                                   choosing to
>>>                                   � �accept the risk
>>>                                   � �> items to some users, those 
>>> services
>>>                    will get a
>>>                                   bad reputation
>>>                                   � �and people
>>>                                   � �> will choose different asset
>>>         services
>>>                    instead.
>>>                                   �Likewise, if a
>>>                                   � �world service
>>>                                   � �> people, users will get annoyed
>>>         at the
>>>                    lag and will go
>>>                                   � �elsewhere. �This user
>>>                                   � �> evaluation and "voting with 
>>> their
>>>                    feet" happens
>>>                                   already with
>>>                                   � �online services
>>>                                   � �> all over the Internet, and I am
>>>         sure
>>>                    that this
>>>                                   human process
>>>                                   � �will continue
>>>                                   � �> to work when the services are 
>>> asset
>>>                    and region
>>>                                   services.
>>>                                   � �>
>>>         this
>>>                    post which
>>>                                   � �> VWRAP a form of asset
>>>         addressing that
>>>                    provides
>>>                                   massive
>>>                                   � �scalability at the
>>>                                   � �> same time as a very high 
>>> degree of
>>>                    resilience --
>>>                                   � �>
>>>                                   �
>>>                                                     
>>>                                   � �> where the hash is generated
>>>         (once, at
>>>                    the time of
>>>                                   storage to
>>>                                   � �the asset
>>>                                   � �> service) using a specified 
>>> digest
>>>                    algorithm over
>>>                                   the content of
>>>                                   � �the asset
>>>                                   � �> being referenced. �You may 
>>> wish to
>>>                    note that if
>>>                                   this design
>>>                                   � �were used, the
>>>                                   � �> failover request for the item
>>>         to one
>>>                    or more
>>>                                   backup services,
>>>                                   � �using the same
>>>                                   � �> hash part but with a 
>>> different host
>>>                    address.
>>>                                   � �>
>>>                                   � �> PS. This design for hash-based
>>>         asset
>>>                    addressing
>>>                                   is already
>>>                                   � �being tested by
>>>                                   � �> Mojito Sorbet in her 
>>> experimental
>>>                    world and
>>>                                   client. �It would give
>>>                                   � �> VWRAP-based worlds an improved
>>>         level
>>>                    of service
>>>                                   availability,
>>>                                   � �so I think it
>>>                                   � �>> This is a question i discussed
>>>         with
>>>                    Morgaine
>>>                                   off-list a while
>>>                                   � �ago (I
>>>                                   � �>> intended to send it to the
>>>         list but
>>>                    pushed the
>>>                                   wrong button...) I
>>>                                   � �>> �In Davids deployment draft,
>>>         section
>>>                    7.3.1.1 an
>>>                                   overview is
>>>                                   � �given van
>>>                                   � �>> capability that allows 
>>> access to
>>>                    (part of) the
>>>                                   resource:
>>>                                   � �>>
>>>                                   � �>> � � � � � 7.3.1.1. �Content
>>>         delivery
>>>                    models
>>>                                   � �>> � � � � � simulation. [...]
>>>         The other
>>>                    end of the
>>>                                   delivery spectrum
>>>                                   � �>> involves passing
>>>                                   � �>> � � � � � only a URI or 
>>> capability
>>>                    used to
>>>                                   access the rendering
>>>                                   � �>> information and a
>>>                                   � �>> � � � � � collision mesh,and
>>>         related
>>>                    data for
>>>                                   physical simulation.
>>>                                   � �>> � � � � � service. �This fetch
>>>         can be
>>>                    done
>>>                                   *under the
>>>                                   � �credentials of the
>>>                                   � �>> end user*
>>>                                   � �>> � � � � � viewing the 
>>> material [my
>>>                    emphasis--VD]
>>>                                   , and
>>>                                   � �divorces the
>>>                                   � �>> simulation from
>>>                                   � �>> � � � � � the trust chain
>>>         needed to
>>>                    manage
>>>                                   content. �Any
>>>                                   � �automation
>>>                                   � �>> is done on a
>>>                                   � �>> � � � � � object through 
>>> remoted
>>>                    interfaces.
>>>                                   � �>>
>>>                                   � �>> �I can see the need for such a
>>>         setup,
>>>                    however, i
>>>                                   feel we are
>>>                                   � �>> unpleasantly close to a 
>>> situation
>>>                    were the
>>>                                   coherence of the
>>>                                   � �simulation
>>>                                   � �>> falls apart.
>>>                                   � �>> In this deployment pattern the
>>>         region
>>>                    advertises
>>>                                   the presence
>>>                                   � �of the
>>>                                   � �>> -based on the arbitrary whims
>>>         of the
>>>                    asset
>>>                                   service- others
>>>                                   � �might not.
>>>                                   � �>>
>>>                                   � �>> My hope would be that after
>>>         the asset
>>>                    server
>>>                                   provides the
>>>                                   � �region with
>>>                                   � �>> the capability to get the
>>>         asset, it
>>>                    gives up
>>>                                   control. That
>>>                                   � �would mean
>>>                                   � �>> the content - in spire of the
>>>         region
>>>                    saying it
>>>                                   is present-,
>>>                                   � �the client
>>>                                   � �>> should be able to turn around
>>>         ask the
>>>                    *region*
>>>                                   for the asset,
>>>                                   � �(and get
>>>                                   � �>> is after all).
>>>                                   � �>>
>>>                                   � �>> deployment pattern as 
>>> described-
>>>                    �shouldn't we
>>>                                   *warn* clients
>>>                                   � �that the
>>>                                   � �>> region might be inconsistent,
>>>         so the
>>>                    users
>>>                                   behind the client
>>>                                   � �can vote
>>>         <mailto:[email-masked]>
>>>         <mailto:[email-masked]>
>>>         <mailto:[email-masked]>
>>>                       Web Development, Software Engineering, Virtual
>>>         Reality,
>>>                    Consultant
>>>

--

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 10 Apr 2011 09:07:03 +0200

Dzonatas,

>There have been talks to split out the renderer from the viewer,
>yet the render depends on some of the network. To call that the
>local region is appropriate as you have.
>The renderer/network-loop does the bulk of the work now that others
>think the simulator does. That's where we get hung up on local sim
>or external sim, and components.

Hmm, to be honest, i was thinking of that local region as a "real"  region,
something like
the opensim region that i have running on my local machine.  I called it
local because it would run on one of my own machines. The entity that i
called "viewer" was supposed to depict something like the standard SL
viewer.

 I see your general point about taking an even higher point of view and drop
some REST details. I will give that a try, it might simplify the figure a
lot.

>I think with your first VD1 that only thing that really needs to be added
is to
>add space between the local and external area to fit in the resource name
per arrow.
>That way the public resource name is specified. Then instead of those
request for
>cap transitions, these would be implied by those resource names. Above each
line of
>each arrow, just add the appropriate public resource name there. We can
deal with
>private resources later, as those are already implied, too.

OK, that sounds sensible, have been thinking about that, but decided against
it since at the time  i was not exactly sure how to specify the resource
names. In relation to that problem you wrote:

>This group never did create any dictionary of resource names. They only
exist in viewer source and >in SNOW-375.

That dictionary would be something we should copy over from SNOW-375 or the
viewer code.
And it reminds me, is it still true hat if i look at that code, that might
prevent me from working on opensim for some time? Would that be the case for
snow-375 code as well?

I can make that new figure, but it will be a few days, i am overloaded with
RL work  :(
Feel free to give it a try based on the PSD file.

-- Vaughn

On Sun, Apr 10, 2011 at 3:27 AM, Dzonatas Sol <[email-masked]> wrote:

>> I think with your first VD1 that only thing that really needs to be added
>> is to add space between the local and external area to fit in the resource
>> name per arrow. That way the public resource name is specified. Then instead
>> of those request for cap transitions, these would be implied by those
>> resource names. Above each line of each arrow, just add the appropriate
>> public resource name there. We can deal with private resources later, as
>> those are already implied, too.
>>
>> This group never did create any dictionary of resource names. They only
>> exist in viewer source and in SNOW-375.
>>
>>> There have been talks to split out the renderer from the viewer, yet the
>>> render depends on some of the network. To call that the local region is
>>> appropriate as you have. The renderer/network-loop does the bulk of the work
>>> now that others think the simulator does. That's where we get hung up on
>>> local sim or external sim, and components.
>>>
>>> Maybe easier not to worry about requests for caps for now and keep the
>>> way your going. We can come back later and describe how the
>>> connections/ReSTful patterns work later. Please just indicate it's the above
>>> ReSTful view of the flow (higher-level) and us implementators will
>>> comprehend.
>>>
>>> =)
>>>
>>> Vaughn Deluca wrote:
>>>
>>>> Dzonatas Sol
>>>> >Then again, split the viewer out for local agent services and maybe it
>>>> will appear trivial.
>>>>
>>>> Right,  Maybe we should consider  *only* the viewer as local, and assume
>>>> all other services are external, just to make the example clear.
>>>> On Fri, Apr 8, 2011 at 9:00 PM, Dzonatas Sol <[email-masked]<mailto:
>>>>    viewer out for local agent services and maybe it will appear trivial.
>>>>
>>>>    Vaughn Deluca wrote:
>>>>
>>>>        deliver my zodiac dress. At least i made a backup of that dress!
>>>>                                  of community and private resources.
>>>> �But
>>>>                   add to the
>>>>                                  � �demand. If the region is proxying
>>>> the
>>>>                   assets, then,
>>>>                                  yes the
>>>>                                  � �region has
>>>>                                  � �that... sure it will cost me, but
>>>> the
>>>>                   simulation
>>>>                                  will be consistent
>>>>                                  � �> The specific trade-off that you
>>>> are
>>>>                   discussing is no
>>>>                                  � �different. �A region
>>>>                                  � �> asset servers over the items in
>>>> the
>>>>                   region, so
>>>>                                  that it can
>>>>                                  � �ensure that
>>>>                                  � �> though, it's a trade-off, since
>>>> the
>>>>                   proxied
>>>>                                  design has very
>>>>                                  � �poor scalability
>>>>                                  � �> If we're going to warn users of
>>>> the
>>>>                   potential for
>>>>                                  inconsistency
>>>>                                  � �in the
>>>>                                  � �> hash part but with a different
>>>> host
>>>>                   address.
>>>>                                  � �>
>>>>                                  � �>> � � � � � viewing the material
>>>> [my
>>>>                   emphasis--VD]
>>>>                                  , and
>>>>                                  � �divorces the
>>>>                                  � �>> simulation from

---

From: Morgaine <[email-masked]>
Date: Sun, 10 Apr 2011 14:11:46 +0100

I think there's a bit of a misunderstanding about the nature of a "message",
Vaughn.  I'll see if I can describe it a little better further down.

On Sat, Apr 9, 2011 at 10:31 PM, Vaughn Deluca <[email-masked]>wrote:

>
> You can't  eliminate those messages even when not checking credentials. The
> roundtrips are anyhow needed to make sure that the communication is actually
> working. Or can we really get away with an UDP style of send and pray?? I
> fail to see how you would be able to realise a substantial gain over what
> will be needed anyhow as bare bone infrastructure and for error
> checking/reporting.  But i might be wrong.
>
>
> In the open content use cases that I described in my previous reply, we can
eliminate entirely the request-grant handshake messages which handle caps,
because the caps are only there as a roadblock against obtaining the item.
When an item is unrestricted, a roadblock against obtaining it is obviously
inappropriate.  What's more, once you have actually obtained the item, a
roadblock against obtaining it again is inappropriate as well, since you
will continue to have the item unless you choose to delete it, in our data
model.  What this *intrinsically* means is that caps are only meaningful as
a mechanism for obtaining the direct address of an item.  In the case of
open content, we already have that direct address. :-)

With regard to message transports, you mention "UDP style", but our
messaging is not related in any way to UDP (not sure what "style" means), as
we are talking about reliable messaging running over TCP in all of this.  A
message will always be received reliably if it is sent successfully.  There
is no return message confirming receipt needed at our level because the TCP
stream does all that under the hood.

A TCP session will be maintained between any two endpoints which exchange
one or more protocol messages.  In an efficient implementation, the same TCP
stream will carry the response message back too, since messages can be sent
over a TCP stream in both directions regardless of who initiated the
connection.

When we speak of a message sent from A to B, we're referring to the message
payload sent by A and received by B across such a TCP stream, and we're
specifically *not* referring to the IP datagrams which are sent in both
directions between A and B to implement the single-direction A->B message
transfer.  Our protocol messaging is at one level of abstraction higher than
that of the packets which implement the TCP stream.

(It may actually be two levels higher if our message payload is carried by
HTTP over TCP.)

In numerous places in your protocol flows, whenever the agent wishes to
introduce an asset into the region, a capability for the asset is first
requested from the asset service, and such a capability must be granted
before the asset can be fetched by any party.  This entails a minimum of two
message trip times before the asset itself is even requested.  Even if both
request and grant messages are efficiently carried on the same TCP stream,
there is still the full request-grant round trip time involved here whenever
this operation is performed.

This is quite unnecessary when there are no distribution restrictions on the
item and you already have its *direct address*.  I'll explain this step in
detail because we have not really discussed the nature of inventories and
metadata much on this list before, and they are relevant to asset access.

First of all, just to be sure that we're on the same page, an inventory is
just a tree structure containing asset metadata at its leaves.  It is not,
for the purposes of this discussion, the graphical thing that appears in
viewers as "Inventory", even though the two are strongly related.

Assets that an agent wears are always assets that are held in an agent's
inventory.  When an asset is in inventory, this implicitly means that its
metadata has been fetched and received, and under normal operation this
asset metadata will be in the viewer's inventory cache.  After all, you
can't expect to wear an item when you don't know whether it is a shoe or a
shirt, so the metadata *must* have been received previously for you to be
able to even begin a request to wear it.

Because the asset's metadata is already known, both the agent service and
the client also already know whether the item has access restrictions on it
or not, because that information is an asset property present in the asset's
metadata.  Knowing that it is not burdened with access restrictions, a
viewer can perform a direct fetch of the asset from the asset service
without any need for credentials, because credentials are irrelevant for
this.  Caps are not needed at all in this case, and it is highly likely that
this will be the most common situation in open worlds, which makes it a very
important use case.

It is worth noting that while inventories are mostly a client-side
implementation detail which can be changed unilaterally, the *metadata* held
by inventories is a very important and separable information type in an
architecture that uses 3rd party asset services, so it needs detailed
examination.

The metadata has to be available to remote parties in the same way as the
data itself is, and the best way of handling this is to make metadata a
separate item normally stored in the same asset service as the data.  The
metadata item will naturally reference the corresponding data item (which is
an N:1 relationship when hash-based addressing is used), and in some cases
can reference more than one data item --- for example, the metadata of a
mesh will commonly reference not only the graphical data required for
rendering in the client but also the collision mesh or bounding box data
required by the region.  These two types of data are separate because it
would be inefficient to require clients or regions to download data that
they do not use.  Our "asset" singleton now turns into a metadata + data
pair.

As a final point about metadata versus data, it should be mentioned that
generally only the data ever has access restrictions placed on it, because
placing restrictions on metadata leads to unsearchable inventories for which
the technical term is "annoying as hell", or more seriously, poorly
functionality and yet another source of lag.  I am going to assume that
nobody wants that and hence, that metadata is never accessed through
capabilities.  If anyone wants to suffer the burden of capabilities for
metadata then they are welcome to do so of course, just as long as the rest
of us do not have to:  "*the burden of a facility should be borne only by
those who need it*".  In the model that I am describing, metadata is
directly addressed and has the same protection as a cryptographic key:  the
address of metadata is an unguessable address, but once you know it, you
know it.

Now that we understand metadata, let's look at how this affects regions.

Regions don't have access to your inventory, but they do have access to the
metadata of each item that is part of the region's simulation, for numerous
reasons.  The primary reason is of course that the metadata contains one or
more references to needed data, but there are other reasons too.  For
example, the region may wish to ensure that every item in its region space
has specific properties which are described in item metadata, such as lack
of access restrictions, or the opposite, requiring certain access
restrictions.  (Note that your requirement for simulation consistency can be
implemented very cleanly that way too --- just add something like
Boolean:RegionConsistency to the set of asset properties).  As another
example, the region may wish to ensure that every item in its space is
properly tagged to support accessibility, so the item type and item
descriptions typically held in metadata would then be important.

Now that we've progressed to this level of detail, we can at last state
precisely what happens when agents inform the region of the items that they
are wearing as avatars:  they are supplying to the region the addresses of
the relevant metadata items.  The region then fetches those metadata items
from the asset service (unless it already has them in cache), and then on
the basis of that metadata, the region begins its decision making about
whether to allow the asset to appear in its region or not.  If the metadata
indicates that no access restrictions are required, then the region can send
the metadata URIs directly to clients.  In contrast, if the metadata says
that the asset data has restricted access, then the region has to engage its
more onerous access control mechanisms, ie. it first obtains an *
AssetAllowedInRegion* capability for the asset from the asset service, which
it then passes to all clients.

Note that this is only one particular design for our protocol flows, and no
doubt other designs can achieve the same functionality and efficiency.  I
expect you were trying to keep things simple for an initial diagram, but as
we get into the detail we have to start considering the role that metadata
plays in asset access because this is actually central to the effective
operation of external asset services.  Your diagram doesn't get down to the
level of metadata access, but we cannot avoid it when we have external asset
services.

A final point about metadata, before this email gets too long.  There may be
many thousands or even millions of instances of a common asset held in
people's inventories, such as those used by default avatars, or trees and
plants and other objects or textures common in the environment, and many
others.  Both our asset services and our caches need store those data items
only once when we use hash-based addressing, instead of millions of times.
The reason we can make this remarkable saving of space is because the *
metadata* is stored as separate items and holds details such as "ownership"
separately, while in terms of storage all those different metadata items can
point at the same asset data.

That N:1 relationship between metadata and data is important as we design
our protocols, because it allows us to avoid those unhelpful and inefficient
designs that require us to download something just to determine whether we
wanted to download it.  By separating the two types of information, we gain
a lot, but it does mean that "asset" cannot be treated as a monolithic
entity as in your diagram.  As we hone our design further, metadata fetches
enter the picture.

Morgaine.

========================

On Sat, Apr 9, 2011 at 10:31 PM, Vaughn Deluca <[email-masked]>wrote:

>> flow could be said to to be targeting some kind of "*superset of all
>> VWRAP deployments*" deployment. :-)  Although it's logically structured,
>> it's a sort of worst-case scenario (or lawyer's delight) in which everyone
>> has to ask everyone else for permission to do anything, regardless of
>> whether permission is actually required or not.
>>
>> That's viable, but less than optimal.  Specifically, you are working to
>> the principle of "The heaviest burden required by anyone must be borne by
>> TO BE RESTRICTED* by the mere fact of asking for caps to everything.
>> This itself is wrong.  The logic need to first determine whether a cap is
>> needed for fetching a given asset, and if it's not needed then the fetch can
>> be done by the viewer or region without this protocol burden at all.
>>
>> So you see, there is a fundamental assumption in your nicely laid out
>> flows that all assets must be tied up in heavy red tape by the needs of the
>> most burdensome use case.  I don't agree with that, neither on principle nor
>> on engineering grounds.
>>
>>> and OAut  or whatever other  magic that I do not yet fully understand exists
>>> out there.
>>>
>>> 25) The zodiac dress was not delivered by Big assets service, but i have
>>> a local copy!
>>>> counts, but its all terminology. The way I read the AWG diagrams is that the
>>>> agent domain is actually a cluster of tightly integrated services. When the
>>>> On Sun, Apr 3, 2011 at 7:20 PM, Dzonatas Sol <[email-masked]>wrote:
>>>>
>>>>> And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset(warn: unstructured collaborative notes, dumped on me and I tried to fix)
>>>>>

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 10 Apr 2011 07:45:21 -0700

The viewer is quite monolithic natured piece of organic development. 
There were some artifacts, at least in source, that showed how 
everything used to be local. There has been some "this name means that 
now, and that name means this now" type of juggle, as the services were 
made apart.

I wrote the documentation about resources in SNOW-375, so I don't mind 
if they are re-documented on the IETF wiki. I agreed with others to keep 
that part of the documentation as CC-by-SA, that way public resources 
stay public assets for reuse. I guess it's best for me to move it to PDF 
format, attach it to the ietf wiki, and start from there?

As for your question to look at (GPL/LGPL) code, I'm not their lawyer. I 
think Compaq was the best example of how and how far that company needed 
to go for clean room, "reverse engineered" work (which is the key legal 
word, at issue, that doesn't play nicely with GPL). Is Compaq still the 
best example?

Vaughn Deluca wrote:
> Hmm, to be honest, i was thinking of that local region as a "real" 
>  region, something like
> the opensim region that i have running on my local machine.  I called 
> it local because it would run on one of my own machines. The entity 
> that i called "viewer" was supposed to depict something like the 
> standard SL viewer.
>
>  I see your general point about taking an even higher point of view 
> and drop some REST details. I will give that a try, it might simplify 
> the figure a lot.
>
> added is to 
> >add space between the local and external area to fit in the resource 
> name per arrow. 
> >cap transitions, these would be implied by those resource names. 
> Above each line of 
> >each arrow, just add the appropriate public resource name there. We 
> can deal with 
> OK, that sounds sensible, have been thinking about that, but decided 
> against it since at the time  i was not exactly sure how to specify 
> the resource names. In relation to that problem you wrote:
>
> only exist in viewer source and >in SNOW-375.
>
> That dictionary would be something we should copy over from SNOW-375 
> or the viewer code.
> And it reminds me, is it still true hat if i look at that code, that 
> might prevent me from working on opensim for some time? Would that be 
> the case for snow-375 code as well?
>
> I can make that new figure, but it will be a few days, i am overloaded 
> with RL work  :(
> On Sun, Apr 10, 2011 at 3:27 AM, Dzonatas Sol <[email-masked] 
>         I think with your first VD1 that only thing that really needs
>         to be added is to add space between the local and external
>         area to fit in the resource name per arrow. That way the
>         public resource name is specified. Then instead of those
>         request for cap transitions, these would be implied by those
>         resource names. Above each line of each arrow, just add the
>         appropriate public resource name there. We can deal with
>         This group never did create any dictionary of resource names.
>         They only exist in viewer source and in SNOW-375.
>
>             There have been talks to split out the renderer from the
>             viewer, yet the render depends on some of the network. To
>             call that the local region is appropriate as you have. The
>             renderer/network-loop does the bulk of the work now that
>             others think the simulator does. That's where we get hung
>             up on local sim or external sim, and components.
>
>             Maybe easier not to worry about requests for caps for now
>             and keep the way your going. We can come back later and
>             describe how the connections/ReSTful patterns work later.
>             Please just indicate it's the above ReSTful view of the
>             flow (higher-level) and us implementators will comprehend.
>
>             =)
>
>             Vaughn Deluca wrote:
>
>                 Dzonatas Sol
>                 >Then again, split the viewer out for local agent
>                 services and maybe it will appear trivial.
>
>                 Right,  Maybe we should consider  *only* the viewer as
>                 local, and assume all other services are external,
>                 just to make the example clear.
>                 On Fri, Apr 8, 2011 at 9:00 PM, Dzonatas Sol
>                 <mailto:[email-masked]>>> wrote:
>
>                        VWRAP services high level message flow
>                 (preliminary diagram
>                        draft) see
>
>                      
>                        So here we go, the avatar is  prepare for a
>                 visit to
>                        "immersive world"
>                        2)  Asset service A, please send a cap for Z,
>                 here are my
>                        credentials
>                        4)  Local region, can you please put this on my
>                 agent, i
>                        included the cap.
>                        11) Local asset storage, please store Z for me,
>                 here is the
>                        cap to get it
>                        28) Local region, can you please put this on my
>                 agent, i
>                        include the cap.
>                        40) Hello immersive world, just  get me there,
>                 and use what
>                        you can
>                 <mailto:[email-masked]>>>> wrote:
>
>                           - Produce a visual that reflects my
>                 thinking, i.e. an
>                        illustration
>                           Regarding the use of domain, I think
>                 services are
>                        eventually what
>                           counts, but its all terminology. The way I
>                 read the AWG
>                        diagrams
>                           integrated services. When the functionality
>                 of each
>                        sub-service is
>                           slowly dissolve. But let not get ahead of
>                 out selfs. We
>                        should put
>                           up some clear descriptions on the wiki for
>                 our views on
>                        this, and
>                           Its been a very useful and illuminating
>                 weekend for me, and
>                        i am a
>                           lot more optimistic about the future of
>                 vwrap than two
>                        weeks ago.
>
>                           -- Vaughn
>
>
>
>                 <mailto:[email-masked]>>>> wrote:
>
>                               Probably easy as suggested in other
>                 terms here on this
>                        list,
>                               Since their is proprietary (legacy) code
>                 then we can't
>                        expect
>                               Eventually, the agent domain is ideal to
>                 handle the
>                        direction
>                               Also see;
>                 http://wiki.secondlife.com/wiki/Agent_Domain
>                               And:
>                              
>                               versions of asset services. Despite
>                 that, I think that
>                        concept
>                               helps view where we were at in
>                 discussion and what
>                        didn't happen.
>
>                               Vaughn Deluca wrote:
>
>                                   Hi�Dzonatas
>
>                                   If i want to read up on how
>                 the�asset server may
>                        proxy the
>                                   <[email-masked]
>                 <mailto:[email-masked]>>
>                 <mailto:[email-masked]>>>
>                 <mailto:[email-masked]>>
>                 <mailto:[email-masked]>>>>>
>
>                                   wrote:
>
>                                      Some stated the
>                                          download assets is now
>                 priority, yet I also
>                                   wondered the best
>                                          way to patch this into the
>                 current mode of
>                        viewers.
>
>                                          Maybe offer (1) by proxy
>                 (sim-side) and (2)
>                        by patch
>                                          (viewer-side) that either of
>                 these two are
>                        optional and
>                                              > when designing for
>                                              and many different use
>                 cases. One particular
>                                              model affects the ability
>                 to host personal
>                                   asset services.
>
>                                              > a proxying region,
>                 which would get slammed
>                                   for every
>                                              asset worn by every
>                 avatar present.
>
>                                              Granted the collection of
>                 services that are
>                                   provided by
>                                              the region need to be
>                 scaled to meet the
>                                   demands of that
>                                              region. That's all part
>                 of capacity
>                        planning.
>
>                                              and absolutely cannot
>                 afford to serve
>                                              Well... who said the same
>                 CPU's have to do
>                                   proxying,
>                                              physics simulation and
>                 server-side
>                        scripting? Asset
>                                              proxying is a different
>                 service than physics
>                                   simulation
>                                              and can be on separate
>                 hardware, could
>                        make use of
>                                              geographically
>                 distributed caching, and
>                        in certain
>                                              deployment patterns, the
>                 same caching
>                        services
>                                   could be
>                                              shared by different
>                 regions. (Server-side
>                                   scripting is a
>                                              Totally agree, and a
>                 proxying model
>                        could and
>                                              you sure you're not
>                 forcing *every* asset
>                                   service to be
>                                              This particular design
>                 decision has a big
>                                   effect on the
>                                              economics of the VW
>                 infrastructure. I'd
>                        rather the
>                                              economics to work out
>                 such that a region
>                                   provider who
>                                              *large* population has to
>                 bear that cost of
>                                   providing that
>                                              scalable asset service.
>                                              I want the economics of
>                 hosting a small
>                        asset
>                                   service to
>                                              be a non-issue (as to
>                 best promote
>                        creation and
>                                              creativity). Creating a
>                 high bar to provide
>                                   asset services
>                                              will mean that service
>                 will cost money
>                        and people
>                                              shouldn't have to pay
>                 money just to
>                        create or
>                                   own VW
>                                              objects (I'm using 'own'
>                 here to refer to
>                                   maintaining
>                                              their existence, I'm not
>                 trying to make a
>                                              'leftist'/'communist'
>                 statement about
>                        ownership ;)
>
>                                              - Izzy
>
>
>                                              On Apr 2, 2011, at 3:58
>                 PM, Morgaine wrote:
>
>                                                  Izzy, when designing for
>                        scalability, the
>                                   model to
>                                                  bear in mind is that
>                 of seasoned
>                        virtual world
>                                                  travelers whose
>                 inventories contain
>                        assets
>                                   from many
>                                                  different worlds,
>                 those assets being
>                        served
>                                   by many
>                                                  different asset
>                 services. �Both
>                        worlds and
>                                   asset
>                                                  services may include
>                 commercial,
>                        community, and
>                                                  personal services,
>                 and as the metaverse
>                                   grows, that
>                                                  set is highly likely
>                 to become
>                                   progressively less
>                                                  clustered and more
>                 diverse.
>
>                                                  When those seasoned
>                 travelers click
>                        on an
>                                   advertised
>                                                  VW link and perform
>                 an inter-world
>                        teleport
>                                   to one
>                                                  particular world's
>                 region to share an
>                                   experience,
>                                                  their "worn" assets
>                 (the only ones of
>                                   interest to the
>                                                  region) will contain
>                 references to asset
>                                   services
>                                                  spread widely across
>                 the Internet. �The
>                                   fetches by the
>                                                  travelers' clients
>                 occur over many
>                        parallel
>                                   paths from
>                                                  clients to asset
>                 services, so one can
>                                   reasonably
>                                                  expect reduced
>                 network contention and
>                                   reduced asset
>                                                  server loading
>                 because they are both
>                        spread
>                                   out over
>                                                  however many asset
>                 services are being
>                                   referenced by
>                                                  the overall set of
>                 assets in the region.
>
>                                                  This is very
>                 different to the case of a
>                                   proxying
>                                                  region, which would
>                 get slammed for
>                        every
>                                   asset worn
>                                                  by every avatar
>                 present. �In our current
>                                   architecture,
>                                                  regions run many
>                 different
>                        CPU-intensive tasks,
>                                                  including physics
>                 simulation and
>                        server-side
>                                                  scripting, and
>                 absolutely cannot
>                        afford to
>                                   serve
>                                                  assets too unless
>                 your scalability
>                                   requirements are
>                                                  very low indeed, ie.
>                 just a few dozen
>                                   avatars of
>                                                  today's kind. �We've
>                 hit the ceiling
>                                   already on region
>                                                  scalability done that
>                 way. �There is
>                                   nowhere to go in
>                                                  that direction at all
>                 beyond
>                        improving the
>                                   code like
>                                                  Intel demonstrated,
>                 and that work is
>                                   subject to a law
>                                                  of diminishing returns.
>
>                                                  This is why we have
>                 to go parallel,
>                        and I
>                                   think you're
>                                                  wrong that it has to
>                 cost much
>                        money. �As
>                                   we spread
>                                                  the load across more
>                 and more asset
>                                   services, we are
>                                                  simply better
>                 utilizing all the
>                        hardware that's
>                                                  already out there on
>                 the Internet,
>                        at least
>                                   in respect
>                                                  of community and
>                 private resources. �But
>                                   add to the
>                                                  community and private
>                 resources the
>                                   commercial asset
>                                                  services that are
>                 likely to appear to
>                                   exploit this
>                                                  opportunity, and not
>                 only will the
>                        number
>                                   of asset
>                                                  services leap, but
>                 the power of each one
>                                   will rocket
>                                                  too, because, after
>                 all, these
>                        businesses
>                                   will be
>                                                  heavily optimized for
>                 the job.
>
>                                                  As to why a world
>                 would want clients
>                        to access
>                                                  external asset
>                 services instead of
>                                   providing its own
>                                                  implementation,
>                 that's an easy question.
>                                   �It costs
>                                                  money to host a high
>                 performance and
>                                   scalable asset
>                                                  service and a high
>                 bandwidth network to
>                                   handle the
>                                                  traffic. �A *lot* of
>                 money. �In
>                        contrast,
>                                   it costs a
>                                                  world nothing to let
>                 others serve
>                        the assets to
>                                                  clients. �And that
>                 matters to the
>                        bottom line.
>
>
>                                                  Morgaine.
>
>
>
>
>                                                  ======================
>
>                                                  On Sat, Apr 2, 2011
>                 at 7:05 PM, Izzy
>                        Alanis
>                                                  <[email-masked]
>                 <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked]>>>>
>                                                
>                 <mailto:[email-masked]>>>>>> wrote:
>
>                                                  � �> As always
>                 though, it's a trade-off,
>                                   since the
>                                                  proxied design
>                                                  � �has very poor
>                 scalability
>                        compared to the
>                                                  distributed one.
>
>                                                  � �I don't agree with
>                 that... If a user
>                                   enters a
>                                                  highly populated
>                                                  � �region,
>                                                  � �every other client
>                 is going to (could
>                                   and should be
>                                                  trying to)
>                                                  � �hit the
>                                                  � �asset server(s)
>                 for the assets
>                        that the
>                                   user is
>                                                  wearing (assuming
>                                                  � �they're not cached
>                 locally). �Every
>                                   asset server
>                                                  has to be scaled up
>                                                  � �to the point that
>                 it can handle that
>                                   load from all
>                                                  over...
>
>                                                  � �If I'm hosting a
>                 region that
>                        supports 10s of
>                                                  thousands of
>                                                  � �simultaneous
>                                                  � �users (thinking of
>                 the future), I
>                                   already have to
>                                                  scale to meet that
>                                                  � �demand. If the
>                 region is proxying the
>                                   assets, then,
>                                                  yes the
>                                                  � �region has
>                                                  � �to be scaled to
>                 meet that asset
>                        demand
>                                   too, but it
>                                                  already has to be
>                                                  � �scaled to meet
>                 other demands of
>                        being a
>                                   region
>                                                  server... and why is
>                                                  � �scaling those
>                 asset proxy
>                        services hard?
>                                   �It's
>                                                  going to cost $,
>                                                  � �but is
>                                                  � �not technically
>                 challenging. So, if I
>                                   want to host
>                                                  a region like
>                                                  � �that... sure it
>                 will cost me, but the
>                                   simulation
>                                                  will be consistent
>                                                  � �and users will be
>                 able to participate
>                                   equally,
>                                                  regardless of the
>                                                  � �capabilities of
>                 their individual
>                        asset
>                                   services.
>
>
>
>
>                                                  � �On Fri, Apr 1,
>                 2011 at 11:55 PM,
>                        Morgaine
>                                                  �
>                 �<[email-masked]
>                 <mailto:[email-masked]>>>>
>                                                  �
>                 <mailto:[email-masked]>>>>>> wrote:
>                                                  � �> Every design
>                 choice results in a
>                                   trade-off,
>                                                  Vaughn, improving
>                                                  � �one thing at
>                                                  � �> the expense of
>                 something else. �If
>                                   every time we
>                                                  offered a
>                                                  � �service we had to
>                                                  � �> inform its users
>                 about the
>                        downsides
>                                   of all the
>                                                  trade-offs we
>                                                  � �have made,
>                                                  � �> they would have
>                 an awful lot to
>                        read. ;-)
>                                                  � �>
>                                                  � �> The specific
>                 trade-off that you are
>                                   discussing is no
>                                                  � �different. �A region
>                                                  � �> that proxies all
>                 content has the
>                                   "benefit" of
>                                                  acquiring control
>                                                  � �from the
>                                                  � �> asset servers
>                 over the items in the
>                                   region, so
>                                                  that it can
>                                                  � �ensure that
>                                                  � �> everyone in the
>                 region not only
>                                   obtains the items
>                                                  but obtains
>                                                  � �the same items
>                                                  � �> as everyone
>                 else. �That does indeed
>                                   provide a
>                                                  greater guarantee of
>                                                  � �> consistency than
>                 a deployment
>                        in which
>                                   the region
>                                                  only passes
>                                                  � �asset URIs to
>                                                  � �> clients who then
>                 fetch the
>                        items from
>                                   asset services
>                                                  � �> though, it's a
>                 trade-off, since the
>                                                  � �> If we're going
>                 to warn users of the
>                                                  � �> anyway. �In any
>                 case, the better
>                                   services are
>                                                  � �> information in
>                 their online
>                                   documentation, I
>                                                  � �> items to some
>                 users, those services
>                                                  � �> evaluation and
>                 "voting with their
>                                                  � �> to work when the
>                 services are asset
>                                                  � �> same time as a
>                 very high degree of
>                                                  � �> service) using a
>                 specified digest
>                                                  � �> being
>                 referenced. �You may wish to
>                                   note that if
>                                                  this design
>                                                  � �were used, the
>                                                  � �> failure of an
>                 asset service to
>                        deliver a
>                                                  requested item would
>                                                  � �result in a
>                                                  � �> failover request
>                 for the item
>                        to one
>                                   or more
>                                                  backup services,
>                                                  � �using the same
>                                                  � �> hash part but
>                 with a different host
>                                   address.
>                                                  � �>
>                                                  � �> This can go some
>                 way towards
>                                   overcoming the
>                                                  problem that you
>                                                  � �think might
>                                                  � �> occur when
>                 assets are fetched by
>                                   clients from
>                                                  asset services
>                                                  � �directly.
>                                                  � �> Although it
>                 won't help when the
>                                   missing item is
>                                                  available from
>                                                  � �only a single
>                                                  � �> asset service,
>                 it will help in many
>                                   other cases,
>                                                  and it will
>                                                  � �compensate for
>                                                  � �> service failures
>                 and network
>                        outages
>                                                  � �> Mojito Sorbet in
>                 her experimental
>                                                  � �> should be a core
>                 feature of our
>                                                  � �> On Fri, Apr 1,
>                 2011 at 11:17 PM,
>                                   Vaughn Deluca
>                 �<[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked]>>>>>>
>                                                  � �> wrote:
>                                                  � �>>
>                                                  � �>> This is a
>                 question i discussed
>                        with
>                                   Morgaine
>                                                  off-list a while
>                                                  � �ago (I
>                                                  � �>> intended to
>                 send it to the
>                        list but
>                                   pushed the
>                                                  wrong button...) I
>                                                  � �>> think we need
>                 to address this
>                                   problem, and
>                                                  decide how to deal
>                                                  � �with it.
>                                                  � �>>
>                                                  � �>> �In Davids
>                 deployment draft,
>                        section
>                                   7.3.1.1 an
>                                                  overview is
>                                                  � �given van
>                                                  � �>> ways to deliver
>                 content to the
>                                   region. One way
>                                                  is only passing a
>                                                  � �>> capability that
>                 allows access to
>                                   (part of) the
>                                                  resource:
>                                                  � �>>
>                                                  � �>> � � � � �
>                 7.3.1.1. �Content
>                        delivery
>                                   models
>                                                  � �>> � � � � � A
>                 range of possible
>                                   represenations can
>                                                  be passed to
>                                                  � �a region for
>                                                  � �>> � � � � �
>                 simulation. [...]
>                        The other
>                                   end of the
>                                                  delivery spectrum
>                                                  � �>> involves passing
>                                                  � �>> � � � � � only
>                 a URI or capability
>                                   used to
>                                                  access the rendering
>                                                  � �>> information and a
>                                                  � �>> � � � � �
>                 collision mesh,and
>                        related
>                                   data for
>                                                  physical simulation.
>                                                  � �>> � � � � � In
>                 such a model, the
>                        client is
>                                                  responsible for
>                                                  � �fetching the
>                                                  � �>> additional
>                                                  � �>> � � � � �
>                 information needed to
>                                   render the
>                                                  item's visual
>                                                  � �presence from a
>                                                  � �>> separate
>                                                  � �>> � � � � �
>                 service. �This fetch
>                        can be
>                                   done
>                                                  *under the
>                                                  � �credentials of the
>                                                  � �>> end user*
>                                                  � �>> � � � � �
>                 viewing the material [my
>                                   emphasis--VD]
>                                                  , and
>                                                  � �divorces the
>                                                  � �>> simulation from
>                                                  � �>> � � � � � the
>                 trust chain
>                        needed to
>                                   manage
>                                                  content. �Any
>                                                  � �automation
>                                                  � �>> is done on a
>                                                  � �>> � � � � �
>                 separate host which
>                        the content
>                                                  creator or owner trusts,
>                                                  � �>> interacting
>                 with the
>                                                  � �>> � � � � �
>                 object through remoted
>                                   interfaces.
>                                                  � �>>
>                                                  � �>> �I can see the
>                 need for such a
>                        setup,
>                                   however, i
>                                                  feel we are
>                                                  � �>> unpleasantly
>                 close to a situation
>                                   were the
>                                                  coherence of the
>                                                  � �simulation
>                                                  � �>> falls apart.
>                                                  � �>> In this
>                 deployment pattern the
>                        region
>                                   advertises
>                                                  the presence
>                                                  � �of the
>                                                  � �>> asset, and
>                 *some* clients will be
>                                   able to get it
>                                                  as expected,
>                                                  � �while
>                                                  � �>> -based on the
>                 arbitrary whims
>                        of the
>                                   asset
>                                                  service- others
>                                                  � �might not.
>                                                  � �>>
>                                                  � �>> My hope would
>                 be that after
>                        the asset
>                                   server
>                                                  provides the
>                                                  � �region with
>                                                  � �>> the capability
>                 to get the
>                        asset, it
>                                   gives up
>                                                  control. That
>                                                  � �would mean
>                                                  � �>> that if the
>                 client finds the
>                                   inventory server is
>                                                  unwilling to
>                                                  � �serve
>                                                  � �>> the content -
>                 in spire of the
>                        region
>                                   saying it
>                                                  is present-,
>                                                  � �the client
>                                                  � �>> should be able
>                 to turn around
>                        ask the
>                                   *region*
>                                                  for the asset,
>                                                  � �(and get
>                                                  � �>> is after all).
>                                                  � �>>
>                                                  � �>> �If that is not
>                 the case, -and
>                        there are
>                                                  probably good reasons
>                                                  � �for the
>                                                  � �>> deployment
>                 pattern as described-
>                                   �shouldn't we
>                                                  *warn* clients
>                                                  � �that the
>                                                  � �>> region might be
>                 inconsistent,
>                        so the
>                                   users
>                                                  behind the client
>                                                  � �can vote
>                                                  � �>> with their
>                 feet, (or take the
>                        risk)?
>                                                  � �>>
>                                                  � �>> --Vaughn
>                                                  � �>>
>                                  
>                 <mailto:[email-masked]>>>>
>                                                
>                 <mailto:[email-masked]>>>>>
>
>                                                  � �>>
>                                  
>                 <mailto:[email-masked]>>>>>
>
>                                                  � �>
>                                  
>                               Web Development, Software Engineering,
>                 Virtual Reality,
>                        Consultant
>
>
>
>                      
>                 Reality, Consultant

--

---

From: Boroondas Gupte <[email-masked]>
Date: Sun, 10 Apr 2011 23:27:13 +0200

Hi Morgaine

The distinction between metadata and 'content' and storing them in
separately acquirable chunks is a good and quite important idea, I
think. More generally, I can think of several reasons to split a
monolithic data entity E into several separate ones, connected by
referencing each other or by being referenced by a common meta-entity
which replaces the previous monolithic entity:

   1. Several other entities are expected to have some parts in common
      with E, without having other parts in common with it.
   2. Some parties only need some parts of E, but not other parts.
   3. Some parties are only allowed access to some parts of E, but not
      to other parts.

(You might note the similarity between reason (1) and rules used for
database normalization.)

If the entities are immutable (which assets should be according to
previous discussion
<http://www.ietf.org/mail-archive/web/vwrap/current/threads.html#00796>), (1)
can not only occur between unrelated items but will also be very common
for items that result from changing a previous item. Some examples how
this applies specifically to the metadata-content separation (assuming a
similar inventory UI as we have in SL):

    * You rez an object from inventory, resize it, and take it back into
      inventory (which creates a new item there).
          o Same metadata (permissions, name(?), owner)
                + (What about a 'last edited' date, though? SL doesn't
                  seem to store one, but some VWRAP systems might want
                  to keep that info.)
          o Different content
    * You rename an item in-inventory
          o Different metadata (maybe ... see below)
          o Same content
    * You change next-owner permissions on an item, then give it to someone
          o Different metadata
          o Same content

Reason (2) off course occurs when browsing your inventory. If you just
want to e.g. read the names of your items, you don't have to fetch all
the associated content data.

Off course, there are more potential separations that fit one or several
of these three reasons than just the metadata-content one. In SL, having
objects being composed of prims, having prims reference textures for
their faces instead of having the texture data lumped into their own
data, or gestures being composed of steps some of which can reference
animation and sound assets are other examples of such separations.

On 04/10/2011 03:11 PM, Morgaine wrote:
> implementation detail which can be changed unilaterally, the
> /metadata/ held by inventories is a very important and separable
> information type in an architecture that uses 3rd party asset
> services, so it needs detailed examination.
>
> The metadata has to be available to remote parties in the same way as
> the data itself is, and the best way of handling this is to make
> metadata a separate item normally stored in the same asset service as
> the data.
As far as I know, this differs slightly from the concepts/architecture
in SL. This might be a good thing, but because it is almost, but not
completely, the same, we should be aware of these differences: In SL,
there are the concept of assets (which are what I called 'content'
above) and the concept of inventory items, referencing these assets and
holding additional information such as permissions, name, etc. These
inventory items themselves however are *not* considered assets in SL.

So far, that's just a difference in nomenclature, I guess. But the SL
inventory items are also handled differently from SL assets: They aren't
stored (and served to the region) by the asset server, like assets are,
but instead by the inventory service, which also serves the inventory
tree. In fact, at least in the viewer's data model, the folders making
up that tree are just special inventory items that do not reference
assets but reference other inventory items.

One of the drawbacks of how SL draws the line between inventory (-items)
and assets is that it's probably difficult to implement something like
VWR-2427 <https://jira.secondlife.com/browse/VWR-2427>. Treating the
item-metadata as a type of assets as you seem to suggest might allow to
better exploit the commonality that both inventory items and some data
assets can refer to other assets.

(Note that I'm not really an expert on SL's internal architecture, and
most of the above is based on hear-say and some viewer code comments I
remember. Please correct me if I'm wrong somewhere.)

> The metadata item will naturally reference the corresponding data item
> (which is an N:1 relationship when hash-based addressing is used), and
> in some cases can reference more than one data item --- for example,
> the metadata of a mesh will commonly reference not only the graphical
> data required for rendering in the client but also the collision mesh
> or bounding box data required by the region.
Wouldn't it make more sense to keep the metadata-item-to-data-item
relation strictly N:1, and have the mesh data item have a N:N relation
to it's components? (Analogous to SL gestures.) While the item type
should be part of the metadata, I don't think the metadata's structure
should depend on the item type. After all, the structure of inodes of a
file system also doesn't depend on the file formats of the referenced files.

> These two types of data are separate because it would be inefficient
> to require clients or regions to download data that they do not use. 
> Our "asset" singleton now turns into a metadata + data pair.
Yep.

> As a final point about metadata versus data, it should be mentioned
> that generally only the data ever has access restrictions placed on it,
No restrictions for whom? Just for the user whose inventory it is (but
then he/she has to authenticate somehow) or no restrictions for anyone?

> because placing restrictions on metadata leads to unsearchable
> inventories for which the technical term is "annoying as hell", or
> more seriously, poorly functionality and yet another source of lag.
I agree everyone should be able to access their own inventory tree,
including the item-metadata at its leaf nodes. For the tree part, you
later write
> Regions don't have access to your inventory [...]
("inventory" here refers to just the tree, if I understood you
correctly). I guess this is also the case for other users, except where
I have given them explicit permission to view parts of my inventory (if
the protocol was capable of that).

> I am going to assume that nobody wants that [poor functionality and
> lag] and hence, that metadata is never accessed through capabilities.
Now here I'm beginning to wonder, what data all is part of the tree
(that others aren't able to access) and what is instead part of the
item-metadata, (a fraction of) which needs to be broadcasted to other
users, as it contains the references to the assets those other users
have to fetch to render my avatar correctly. For example, is the item
name part of that metadata or part of the tree? It obviously isn't
needed by others, it's merely a reminder for myself of what that item is.

If the item name for worn stuff /is/ broadcasted together with the other
relevant metadata, that's OK as long as the user is aware of it, but it
/does/ have some consequences: In that case, I probably wouldn't want to
name a wearable "The dress that this stupid guy bought me, but that I
like to wear anyway" or "Those shoes that my secret lover Example
Resident gave me" but something more innocent, so that I wouldn't upset
that other user and wouldn't leak that Example Resident was my secret lover.

There might be other metadata that's useful to the users themselves but
that they might want to withhold from region owners and other users.
Imagine for example information about where and when you acquired an
item, which allows you to efficiently search for that item when you
forgot the item name but still remember how you got it. However, if that
info is broadcasted for worn items and you wear enough different items,
everyone around you has a partial trace of your virtual travels.

So we can either split the metadata asset according to reason (3) above
into several assets with different access policies. Or we just lump
metadata we want to keep private together with the tree while only
having metadata we don't mind sharing in the metadata assets.

Cheers,
Boroondas

---

From: Morgaine <[email-masked]>
Date: Mon, 11 Apr 2011 04:25:20 +0100

Excellent response, Boroondas, full of detailed analysis! :-)

I won't respond to everything in-line because it would be mostly a long
sequence of "Yes!" and "Good idea!", but I'll expand in a couple of areas
where your reply makes me think that I should have been clearer, and also
where I prefer your suggestions to mine.

What's more, I'll adopt your suggested nomenclature straight away:

*asset == (metadata + content)*

I like that!  "Metadata + data" has never felt right, because everything is
"data". :-)

data itself is, and the best way of handling this is to make metadata a
separate item normally stored in the same asset service as the data.

As far as I know, this differs slightly from the concepts/architecture in
SL. This might be a good thing, but because it is almost, but not
completely, the same, we should be aware of these differences: In SL, there
are the concept of assets (which are what I called 'content' above) and the
concept of inventory items, referencing these assets and holding additional
information such as permissions, name, etc. These inventory items themselves
however are *not* considered assets in SL.

So far, that's just a difference in nomenclature, I guess. But the SL
inventory items are also handled differently from SL assets: They aren't
stored (and served to the region) by the asset server, like assets are, but
instead by the inventory service, which also serves the inventory tree. In
fact, at least in the viewer's data model, the folders making up that tree
are just special inventory items that do not reference assets but reference
other inventory items.

One of the drawbacks of how SL draws the line between inventory (-items) and
assets is that it's probably difficult to implement something like
VWR-2427<https://jira.secondlife.com/browse/VWR-2427>.
Treating the item-metadata as a type of assets as you seem to suggest might
allow to better exploit the commonality that both inventory items and some
data assets can refer to other assets.

(Note that I'm not really an expert on SL's internal architecture, and most
of the above is based on hear-say and some viewer code comments I remember.
Please correct me if I'm wrong somewhere.)

I'm not an expert on SL's architecture either, but our discussions in the
AWG over 3+ years suggest that your analysis above is correct.  We are
actually sticking fairly closely to the *conceptual* model used in SL (not
for compatibility, but because it is a reasonable model), but we are
departing from SL's *physical* model in some significant ways to gain better
functional properties.

According to the very rough consensus in AW Groupies (:P), in SL only the *
content* is stored in *asset storage*, whereas *metadata* is stored in
a *relational
database* (and is mutable).  In the design that we are discussing here for
VWRAP asset services, both *content* and *metadata *are held in asset
services, and both types of data are immutable.  Our "updates" are achieved
simply by referring to new metadata.

SL handles its metadata specially and caches it in an inventory cache
separately from content, whereas we store and cache them uniformly in both
asset services and caches.  Our inventories merely organize our cached
metadata into a hierarchical *view*.  We're building on past experience to
improve functionality and performance and scalability (and elegance too!),
which is quite natural.

The "information about assets" stored at the leaves of inventories in
SL-compatible clients is conceptually very similar to the metadata stored in
our proposed asset services.  Even the content referencing model is similar,
in the sense that capabilities are used in SL to obtain the UUIDs of
textures for example, and these UUIDs are then stored in the metadata held
in inventory items.

In other words, UUIDs held in SL inventory leaves are equivalent to our *direct
addresses* (URIs) held in metadata.  In both cases, once you have the UUID
or *direct address*, you no longer need a capability to obtain the item.
The cap's only function is to control acquisition of the UUID, which is the
actual address of the content.  Our content URIs just extend the concept of
an address to external asset services.

>> The metadata item will naturally reference the corresponding data item
(which is an N:1 relationship when hash-based addressing is used), and in
some cases can reference more than one data item --- for example, the
metadata of a mesh will commonly reference not only the graphical data
required for rendering in the client but also the collision mesh or bounding
box data required by the region.

> Wouldn't it make more sense to keep the metadata-item-to-data-item
relation strictly N:1, and have the mesh data item have a N:N relation to
it's components? (Analogous to SL gestures.) While the item type should be
part of the metadata, I don't think the metadata's structure should depend
on the item type. After all, the structure of inodes of a file system also
doesn't depend on the file formats of the referenced files.

Yes!  That makes more sense.  I withdraw my N:M suggestion. :-)  Let's stick
with N:1 and then be more clever with content if needed later.  This is also
in keeping with my cost engineering mantra, namely "The burden of X should
be borne only by those who need X".  There is no sense complicating metadata
to make it N:M when the vast majority of its use cases are N:1.

 >> As a final point about metadata versus data, it should be mentioned that
generally only the data ever has access restrictions placed on it,

Sorry, I was ambiguous.  What I should have said was "Only access to the
content of assets may be restricted by access controls, and only when it is
appropriate to do so (eg. never for open content).  Access to the metadata
of assets is never restricted, for anyone.  When access controls restrict
access to the content of a particular asset, then different policies may be
applied to agents who hold assets in inventory and agents who merely render
assets worn by others in the region.  The asset service holds authority over
the asset, and has the power to discriminate."

> ("inventory" here refers to just the tree, if I understood you correctly).
I guess this is also the case for other users, except where I have given
them explicit permission to view parts of my inventory (if the protocol was
capable of that).

I do not envisage anyone ever having access to an agent's inventory, other
than the agent who owns the inventory (inventories are client-side after
all, despite also being saved server-side).  Only the metadata that an
inventory may be referencing can ever be seen by others (for example, when a
region provides the references), but never the hierarchical structure.  This
is similar to how SL/Opensim works:  you can inspect the metadata of an
asset in the scene and see that it is owned by user X, but you have no
access to X's inventory.

>> I am going to assume that nobody wants that [poor functionality and lag]
and hence, that metadata is never accessed through capabilities.

> Now here I'm beginning to wonder, what data all is part of the tree (that
others aren't able to access) and what is instead part of the item-metadata,
(a fraction of) which needs to be broadcasted to other users, as it contains
the references to the assets those other users have to fetch to render my
avatar correctly. For example, is the item name part of that metadata or
part of the tree? It obviously isn't needed by others, it's merely a
reminder for myself of what that item is.

Just in case I wasn't clear before, I'll underline that inventory trees are
entirely unrelated to the process by which others gain access to assets
(they use metadata which links to content, not inventories).  The only
reason why I mentioned inventories at all is because they too happen to
point to metadata.  As to the question of what is in inventories that isn't
in metadata, the answer is "almost nothing" other than the hierarchical
skeleton of named folders.  I guess it's possible to have local symlinks,
and even to modify the metadata locally if desired, for example to change
the local name of an item, but those are just frills.  Generally, inventory
is merely metadata organized locally into a tree.

> If the item name for worn stuff *is* broadcasted together with the other
relevant metadata, that's OK as long as the user is aware of it, but it *
does* have some consequences: In that case, I probably wouldn't want to name
a wearable "The dress that this stupid guy bought me, but that I like to
wear anyway" or "Those shoes that my secret lover Example Resident gave me"
but something more innocent, so that I wouldn't upset that other user and
wouldn't leak that Example Resident was my secret lover.

Haha. :-)  Well it's already the case in SL that the metadata is
inspectable, so people are already used to the fact that how they name
objects and what they write in object descriptions is visible publicly,
nothing new there.

> There might be other metadata that's useful to the users themselves but
that they might want to withhold from region owners and other users. Imagine
for example information about where and when you acquired an item, which
allows you to efficiently search for that item when you forgot the item name
but still remember how you got it. However, if that info is broadcasted for
worn items and you wear enough different items, everyone around you has a
partial trace of your virtual travels.

Yes, good ideas for purely local enhancements to inventories. :-)  I'm sure
that inventories can be extended in many useful ways to build upon their
primary role of organizing and referencing metadata.  That could be a very
interesting area.  Anyone with dozens of thousands of objects in inventory
can appreciate very well the need for some new thinking to help us manage
the object explosion. :-)

Morgaine.

======================

On Sun, Apr 10, 2011 at 10:27 PM, Boroondas Gupte <
[email-masked]> wrote:

> separately acquirable chunks is a good and quite important idea, I think.
> More generally, I can think of several reasons to split a monolithic data
> entity E into several separate ones, connected by referencing each other or
> by being referenced by a common meta-entity which replaces the previous
> monolithic entity:
>
>     3. Some parties are only allowed access to some parts of E, but not to
>    other parts.
>
> previous discussion<http://www.ietf.org/mail-archive/web/vwrap/current/threads.html#00796>),
> (1) can not only occur between unrelated items but will also be very common
> for items that result from changing a previous item. Some examples how this
> applies specifically to the metadata-content separation (assuming a similar
> inventory UI as we have in SL):
>
>    - You rez an object from inventory, resize it, and take it back into
>       - Same metadata (permissions, name(?), owner)
>          - (What about a 'last edited' date, though? SL doesn't seem to
>          store one, but some VWRAP systems might want to keep that info.)
>           - Different content
>    - You rename an item in-inventory
>       - Different metadata (maybe ... see below)
>        - Same content
>    - You change next-owner permissions on an item, then give it to someone
>       - Different metadata
>       - Same content
>
> Reason (2) off course occurs when browsing your inventory. If you just want
> to e.g. read the names of your items, you don't have to fetch all the
> associated content data.
>
> Off course, there are more potential separations that fit one or several of
> these three reasons than just the metadata-content one. In SL, having
> objects being composed of prims, having prims reference textures for their
> faces instead of having the texture data lumped into their own data, or
> gestures being composed of steps some of which can reference animation and
> sound assets are other examples of such separations.
>
> implementation detail which can be changed unilaterally, the *metadata*held by inventories is a very important and separable information type in an
> separate item normally stored in the same asset service as the data.
>
> As far as I know, this differs slightly from the concepts/architecture in
> SL. This might be a good thing, but because it is almost, but not
> completely, the same, we should be aware of these differences: In SL, there
> are the concept of assets (which are what I called 'content' above) and the
> concept of inventory items, referencing these assets and holding additional
> information such as permissions, name, etc. These inventory items themselves
> however are *not* considered assets in SL.
>
> stored (and served to the region) by the asset server, like assets are, but
> instead by the inventory service, which also serves the inventory tree. In
> fact, at least in the viewer's data model, the folders making up that tree
> are just special inventory items that do not reference assets but reference
> other inventory items.
>
> (Note that I'm not really an expert on SL's internal architecture, and most
> of the above is based on hear-say and some viewer code comments I remember.
> Please correct me if I'm wrong somewhere.)
>
> (which is an N:1 relationship when hash-based addressing is used), and in
> some cases can reference more than one data item --- for example, the
> metadata of a mesh will commonly reference not only the graphical data
> required for rendering in the client but also the collision mesh or bounding
> box data required by the region.
>
> Wouldn't it make more sense to keep the metadata-item-to-data-item relation
> strictly N:1, and have the mesh data item have a N:N relation to it's
> components? (Analogous to SL gestures.) While the item type should be part
> of the metadata, I don't think the metadata's structure should depend on the
> item type. After all, the structure of inodes of a file system also doesn't
> depend on the file formats of the referenced files.
>
> These two types of data are separate because it would be inefficient to
> require clients or regions to download data that they do not use.  Our
> "asset" singleton now turns into a metadata + data pair.
>
> Yep.
>
> generally only the data ever has access restrictions placed on it,
>
> No restrictions for whom? Just for the user whose inventory it is (but then
> he/she has to authenticate somehow) or no restrictions for anyone?
>
>  because placing restrictions on metadata leads to unsearchable inventories
> for which the technical term is "annoying as hell", or more seriously,
> poorly functionality and yet another source of lag.
>
> including the item-metadata at its leaf nodes. For the tree part, you later
> write
>
> ("inventory" here refers to just the tree, if I understood you correctly).
> I guess this is also the case for other users, except where I have given
> them explicit permission to view parts of my inventory (if the protocol was
> capable of that).
>
> I am going to assume that nobody wants that [poor functionality and lag]
> and hence, that metadata is never accessed through capabilities.
>
> Now here I'm beginning to wonder, what data all is part of the tree (that
> others aren't able to access) and what is instead part of the item-metadata,
> (a fraction of) which needs to be broadcasted to other users, as it contains
> the references to the assets those other users have to fetch to render my
> avatar correctly. For example, is the item name part of that metadata or
> part of the tree? It obviously isn't needed by others, it's merely a
> reminder for myself of what that item is.
>
> If the item name for worn stuff *is* broadcasted together with the other
> relevant metadata, that's OK as long as the user is aware of it, but it *
> does* have some consequences: In that case, I probably wouldn't want to
> name a wearable "The dress that this stupid guy bought me, but that I like
> to wear anyway" or "Those shoes that my secret lover Example Resident gave
> me" but something more innocent, so that I wouldn't upset that other user
> and wouldn't leak that Example Resident was my secret lover.
>
> that they might want to withhold from region owners and other users. Imagine
> for example information about where and when you acquired an item, which
> allows you to efficiently search for that item when you forgot the item name
> but still remember how you got it. However, if that info is broadcasted for
> worn items and you wear enough different items, everyone around you has a
> partial trace of your virtual travels.
>
> into several assets with different access policies. Or we just lump metadata
> we want to keep private together with the tree while only having metadata we
> don't mind sharing in the metadata assets.
>
> Cheers,
> Boroondas
>

---

From: Morgaine <[email-masked]>
Date: Mon, 11 Apr 2011 05:22:21 +0100

I'd better tighten up one paragraph I wrote, because it could be interpreted
as "all metadata is public", which wasn't intended.  Here's an improved
version:

"Access to the *content* of a restricted asset may be achieved by first
acquiring a capability for that asset.  A capability needs to be acquired
only when that asset's metadata indicates that the content is restricted.
Access to the *metadata* of an asset is never restricted, for anyone, once
an asset has been placed in-world.  Until an asset is placed in-world, its
metadata address is not known to anyone except the owner of the asset, and
is unguessable.  When an asset service restricts access to the content of a
particular asset, then different policies may be applied to agents who hold
assets in inventory and agents who merely render assets worn by others in
the region.  The asset service holds authority over the asset, and has the
power to discriminate."

And further on access controls, a point which we haven't yet discussed:

"If access to the content of a restricted asset is attempted without using a
capability, the access attempt will be rejected by the asset service because
insufficient credentials were provided.  Consequently, simply removing the *
Restricted* property from a restricted asset's metadata in order to avoid
requesting a capability cannot bypass required access controls."

Those are actually reasonable paragraphs for a draft document describing the
design model of VWRAP asset services, assuming there is agreement. :-)

Morgaine.

On Mon, Apr 11, 2011 at 4:25 AM, Morgaine <[email-masked]>wrote:

> <cut>

On Mon, Apr 11, 2011 at 4:25 AM, Morgaine <[email-masked]>wrote:

> the data itself is, and the best way of handling this is to make metadata a
> departing from SL's *physical* model in some significant ways to gain
> better functional properties.
>
> According to the very rough consensus in AW Groupies (:P), in SL only the
> *content* is stored in *asset storage*, whereas *metadata* is stored in a
> *relational database* (and is mutable).  In the design that we are
> discussing here for VWRAP asset services, both *content* and *metadata *are
> held in asset services, and both types of data are immutable.  Our "updates"
> are achieved simply by referring to new metadata.
>
> Yes!  That makes more sense.  I withdraw my N:M suggestion. :-)  Let's
> stick with N:1 and then be more clever with content if needed later.  This
> is also in keeping with my cost engineering mantra, namely "The burden of X
> should be borne only by those who need X".  There is no sense complicating
> metadata to make it N:M when the vast majority of its use cases are N:1.
>
>
>
> correctly). I guess this is also the case for other users, except where I
> have given them explicit permission to view parts of my inventory (if the
> protocol was capable of that).
>
>
>> want to e.g. read the names of your items, you don't have to fetch all the
>> associated content data.
>>
>> inventories for which the technical term is "annoying as hell", or more
>> seriously, poorly functionality and yet another source of lag.
>>

---

From: Morgaine <[email-masked]>
Date: Mon, 11 Apr 2011 07:30:40 +0100

Notice how, by making the use of capabilities dependent on the presence of
the *Restricted* bit in the asset's metadata, we have introduced the
possibility of making VWRAP asset access control flexible and extensible.
This single control bit is just the start. :-)

Where currently we have just one access control bit in the metadata
properties field and one capability mechanism to match, we could have a
vector of control bits or a multi-bit field instead, each bit or the value
of the field activating a different access control mechanism, perhaps to
acquire different types of access credentials.

This could open up many new possibilities, beyond user/region asset
controls.

Morgaine.

======================

On Mon, Apr 11, 2011 at 5:22 AM, Morgaine <[email-masked]>wrote:

>
> "If access to the content of a restricted asset is attempted without using
> a capability, the access attempt will be rejected by the asset service
> because insufficient credentials were provided.  Consequently, simply
> removing the *Restricted* property from a restricted asset's metadata in
> order to avoid requesting a capability cannot bypass required access
> controls."
>
>
> Morgaine.
>
>
>
>
>> I like that!  "Metadata + data" has never felt right, because everything
>> is "data". :-)
>>
>>
>>
>>
>> actually sticking fairly closely to the *conceptual* model used in SL
>> (not for compatibility, but because it is a reasonable model), but we are
>> metadata into a hierarchical *view*.  We're building on past experience
>> to improve functionality and performance and scalability (and elegance
>> too!), which is quite natural.
>>
>> addresses* (URIs) held in metadata.  In both cases, once you have the
>> UUID or *direct address*, you no longer need a capability to obtain the
>> item.  The cap's only function is to control acquisition of the UUID, which
>> is the actual address of the content.  Our content URIs just extend the
>> concept of an address to external asset services.
>>
>>
>> item-metadata, (a fraction of) which needs to be broadcasted to other users,
>> as it contains the references to the assets those other users have to fetch
>> to render my avatar correctly. For example, is the item name part of that
>> metadata or part of the tree? It obviously isn't needed by others, it's
>> merely a reminder for myself of what that item is.
>>
>>
>> Just in case I wasn't clear before, I'll underline that inventory trees
>> are entirely unrelated to the process by which others gain access to assets
>> > If the item name for worn stuff *is* broadcasted together with the
>> other relevant metadata, that's OK as long as the user is aware of it, but
>> it *does* have some consequences: In that case, I probably wouldn't want
>> to name a wearable "The dress that this stupid guy bought me, but that I
>> like to wear anyway" or "Those shoes that my secret lover Example Resident
>> gave me" but something more innocent, so that I wouldn't upset that other
>> user and wouldn't leak that Example Resident was my secret lover.
>>
>> Yes, good ideas for purely local enhancements to inventories. :-)  I'm
>> sure that inventories can be extended in many useful ways to build upon
>> their primary role of organizing and referencing metadata.  That could be a
>> very interesting area.  Anyone with dozens of thousands of objects in
>> inventory can appreciate very well the need for some new thinking to help us
>> manage the object explosion. :-)
>>
>>
>> Morgaine.
>>
>>
>>
>>
>> ======================
>>
>>> to it's components? (Analogous to SL gestures.) While the item type should
>>> be part of the metadata, I don't think the metadata's structure should
>>> depend on the item type. After all, the structure of inodes of a file system
>>> also doesn't depend on the file formats of the referenced files.
>>>
>>> *does* have some consequences: In that case, I probably wouldn't want to