Re: [vwrap] [wvrap] Simulation consistency

[Dzonatas Sol <[e-mail]>]

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

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

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


Vaughn Deluca wrote:
> Dzonatas,
>
> >There have been talks to split out the renderer from the viewer, 
> >yet the render depends on some of the network. To call that the 
> >local region is appropriate as you have. 
> >The renderer/network-loop does the bulk of the work now that others 
> >think the simulator does. That's where we get hung up on local sim 
> >or external sim, and components.
>
> Hmm, to be honest, i was thinking of that local region as a "real" 
>  region, something like
> the opensim region that i have running on my local machine.  I called 
> it local because it would run on one of my own machines. The entity 
> that i called "viewer" was supposed to depict something like the 
> standard SL viewer.
>
>  I see your general point about taking an even higher point of view 
> and drop some REST details. I will give that a try, it might simplify 
> the figure a lot.
>
> >I think with your first VD1 that only thing that really needs to be 
> added is to 
> >add space between the local and external area to fit in the resource 
> name per arrow. 
> >That way the public resource name is specified. Then instead of those 
> request for 
> >cap transitions, these would be implied by those resource names. 
> Above each line of 
> >each arrow, just add the appropriate public resource name there. We 
> can deal with 
> >private resources later, as those are already implied, too.
>
> OK, that sounds sensible, have been thinking about that, but decided 
> against it since at the time  i was not exactly sure how to specify 
> the resource names. In relation to that problem you wrote:
>
> >This group never did create any dictionary of resource names. They 
> only exist in viewer source and >in SNOW-375.
>
> That dictionary would be something we should copy over from SNOW-375 
> or the viewer code.
> And it reminds me, is it still true hat if i look at that code, that 
> might prevent me from working on opensim for some time? Would that be 
> the case for snow-375 code as well?
>
> I can make that new figure, but it will be a few days, i am overloaded 
> with RL work  :(
> Feel free to give it a try based on the PSD file.
>
> -- Vaughn
>
> On Sun, Apr 10, 2011 at 3:27 AM, Dzonatas Sol <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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]>
>                 <mailto:[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]>>
>                        <mailto:[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]>>
>                           <mailto:[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]>>>
>                                   <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:
>
>                                      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]>>>>
>                                                
>                  <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]
>                 <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]>>>>
>                                                  �
>                        �<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]
>                 <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]>>>>
>                                                
>                  <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]
>                 <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]>>>>
>                                                
>                  <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]
>                 <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]>>>>
>                                                
>                  <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]
>                 <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
>                                              �
>
>
>
>
>
>                                      --     ---
>                 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]>>>
>                                   <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
>
>
>
>
>                               --         ---
>                 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
>
>
>
>
>
>
>
>
>     -- 
>     --- https://twitter.com/Dzonatas_Sol ---
>     Web Development, Software Engineering, Virtual Reality, Consultant
>
>


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