Re: [vwrap] [wvrap] Simulation consistency

[Dzonatas Sol <[e-mail]>]

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:
> 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 <[e-mail] 
> <mailto:[e-mail]>> 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.
>     - 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
>
>
>
>     On Sun, Apr 3, 2011 at 7:20 PM, Dzonatas Sol <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         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
>             <[e-mail] <mailto:[e-mail]>
>             <mailto:[e-mail] <mailto:[e-mail]>>>
>             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:
>
>                    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:
>
>
>                        > 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.
>
>
>
>
>                            ======================
>
>                            On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis
>                            <[e-mail]
>             <mailto:[e-mail]> <mailto:[e-mail]
>             <mailto:[e-mail]>>
>                            <mailto:[e-mail]
>             <mailto:[e-mail]>
>
>                            <mailto:[e-mail]
>             <mailto:[e-mail]>>>> 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
>                            � �<[e-mail]
>             <mailto:[e-mail]>
>                            <mailto:[e-mail]
>             <mailto:[e-mail]>>
>                            � �<mailto:[e-mail]
>             <mailto:[e-mail]>
>
>                            <mailto:[e-mail]
>             <mailto:[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]
>             <mailto:[e-mail]>
>                            <mailto:[e-mail]
>             <mailto:[e-mail]>>
>                            <mailto:[e-mail]
>             <mailto:[e-mail]>
>                            <mailto:[e-mail]
>             <mailto:[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]
>             <mailto:[e-mail]> <mailto:[e-mail]
>             <mailto:[e-mail]>>
>                            <mailto:[e-mail]
>             <mailto:[e-mail]> <mailto:[e-mail]
>             <mailto:[e-mail]>>>
>
>                            � �>>
>             https://www.ietf.org/mailman/listinfo/vwrap
>                            � �>
>                            � �>
>                            � �>
>             _______________________________________________
>                            � �> vwrap mailing list
>                            � �> [e-mail] <mailto:[e-mail]>
>             <mailto:[e-mail] <mailto:[e-mail]>>
>                            <mailto:[e-mail]
>             <mailto:[e-mail]> <mailto:[e-mail]
>             <mailto:[e-mail]>>>
>
>                            � �>
>             https://www.ietf.org/mailman/listinfo/vwrap
>                            � �>
>                            � �>
>
>
>
>                      
>              ------------------------------------------------------------------------
>
>                        _______________________________________________
>                        vwrap mailing list
>                        [e-mail] <mailto:[e-mail]>
>             <mailto:[e-mail] <mailto:[e-mail]>>
>                        https://www.ietf.org/mailman/listinfo/vwrap
>                        �
>
>
>
>
>
>                --     --- https://twitter.com/Dzonatas_Sol ---
>                Web Development, Software Engineering, Virtual Reality,
>             Consultant
>
>                _______________________________________________
>                vwrap mailing list
>                [e-mail] <mailto:[e-mail]>
>             <mailto:[e-mail] <mailto:[e-mail]>>
>                https://www.ietf.org/mailman/listinfo/vwrap
>
>
>
>
>         -- 
>         --- https://twitter.com/Dzonatas_Sol ---
>         Web Development, Software Engineering, Virtual Reality, Consultant
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>   


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