Re: [vwrap] [wvrap] Simulation consistency

[Vaughn Deluca <[e-mail]>]

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.   :)

>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.

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?

>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.

Yes!

--Vaughn



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

> 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 <[e-mail]>wrote:
>
>> 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 <[e-mail]>wrote:
>>
>>> 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
>>>
>>> On Sat, Apr 2, 2011 at 5:09 PM, Morgaine <[e-mail]
>>> > wrote:
>>>
>>>> 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 <[e-mail]
>>>> > 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:
>>>>
>>>>
>>>>
>>>> I would like to argue that the region *should* get the capability to
>>>>> 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
>>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> =====================
>>>>
>>>>
>>>> On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca <[e-mail]
>>>> > wrote:
>>>>
>>>>> 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 <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> 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 <
>>>>>> [e-mail]> 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 <
>>>>>>> [e-mail]> 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
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/vwrap
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> vwrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>