Re: [vwrap] [wvrap] Simulation consistency

[Dzonatas Sol <[e-mail]>]

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 <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>>
>>>     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]>
>>>         <mailto:[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]>
>>>            <mailto:[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]>>
>>>                    <mailto:[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]>>>
>>>                                   <mailto:[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]>>>
>>>                                   �
>>>         �<mailto:[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]>>>
>>>                                   <mailto:[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]>>>
>>>                                   <mailto:[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]>>>
>>>                                   <mailto:[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
>>>                               �
>>>
>>>
>>>
>>>
>>>
>>>                       --     --- 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]>>
>>>                    <mailto:[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]>
>>>         https://www.ietf.org/mailman/listinfo/vwrap
>>>        
>>>
>>>     --     --- https://twitter.com/Dzonatas_Sol ---
>>>     Web Development, Software Engineering, Virtual Reality, Consultant
>>>
>>>
>>
>>
>
>


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