[Opensim-dev] Distributed asset server proposal

Mon Nov 3 05:01:07 UTC 2008

In terms of user purchases of content - the simple solution there is to download a copy of the file onto their local system similar to how you download the song when you buy from iTunes. The complexity of inventory and assets nearly evaporates if you consider them to be just a standard filetype.

If the creator wants content to be run remotely (ala subscription services) then they obviously need to keep that service running indefinitely.

Adam

> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
> bounces at lists.berlios.de] On Behalf Of Justin Clark-Casey
> Sent: Sunday, 2 November 2008 7:14 PM
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Distributed asset server proposal
>
> Hurliman, John wrote:
> > That is definitely a goal. The immediate solution we're working on is
> a
> > GridProxy plugin that re-routes asset requests directly to the new
> asset
> > server. It speaks the new REST-based HTTP language on one side, and
> the
> > old UDP-based image transfer system on the client-facing side. The
> next
> > step is a legacy interface for the asset server that acts more like
> SL
> > capabilities and speaks LLSD. It might be possible to mimic the "HTTP
> > Texture Download" interface exactly and have it work out of the box
> with
> > the SL viewer.
> >
> >
> >
> > I used the same approach to make the asset server act as a drop-in
> > replacement for OpenSim.Grid.AssetServer.exe. It connects to the
> assets
> > table in an OpenSim MySQL backend and exposes a REST interface that
> > looks like the existing XML-based grid asset protocol. From there,
> asset
> > migration to other asset servers becomes trivial.
>
> I'm not quite sure what you mean here.
>
> I like the sneaky way you're going to proxy messages to get around the
> licensing and possibly code inflexibility of the
> client.  I guess the approach would be to rig up a proxy that works,
> and use that as a powerful persuasive tool for
> proper client changes, right?
>
> One issue that strikes me with these alternative systems is the
> question of who pays, and continues to pay, for asset
> storage.  Although the LL system of a single  proprietary hidden asset
> service has many disadvantages, in this area it
> is able to provide a very simple system.  A lot of asset storage is
> free (e.g. script revisions, object serializations).
>   Where asset storage does require financing, there is a one-off fee of
> L$10 for storage in perpetuity (image uploads,
> for example).
>
> In a more distributed system, who pays?  The user may have to pay for
> storage instead.  In principle, this could be done
> as a micropayment (a charge each time you save a script), but in
> practice I think it would be much more likely that you
> would pay a fixed monthly fee to some service.
>
> The issue becomes more complicated once a user starts selling items.
> It's probably impossible (?) to pass a recurring
> asset storage fee on to customers.  So one either has to pay an asset
> storage fee forever, or risk a lot of disappointed
> customers if the creator one day will not or cannot pay for continued
> asset storage.
>
> >
> >
> >
> > John
> >
> >
> >
> > *From:* opensim-dev-bounces at lists.berlios.de
> > [mailto:opensim-dev-bounces at lists.berlios.de] *On Behalf Of *Frisby,
> Adam
> > *Sent:* Thursday, October 30, 2008 6:15 PM
> > *To:* opensim-dev at lists.berlios.de
> > *Subject:* Re: [Opensim-dev] Distributed asset server proposal (was:
> RE:
> > OSGrid <-> UCIGrid)
> >
> >
> >
> > It would be nice if we could get the viewer to download the assets it
> > needs directly too rather than route them via the simulator. But of
> > course, protocol changes and LL is always fun.
> >
> >
> >
> > Adam
> >
> >
> >
> > *From:* opensim-dev-bounces at lists.berlios.de
> > [mailto:opensim-dev-bounces at lists.berlios.de] *On Behalf Of
> *Hurliman, John
> > *Sent:* Thursday, 30 October 2008 5:30 PM
> > *To:* opensim-dev at lists.berlios.de
> > *Subject:* [Opensim-dev] Distributed asset server proposal (was: RE:
> > OSGrid <-> UCIGrid)
> >
> >
> >
> > This ties in closely with the asset server proposal we've been
> > brainstorming at Intel. The current version of the proposal is at
> > http://opensimulator.org/wiki/AssetServerProposal and the project
> lives
> > at http://forge.opensimulator.org/gf/project/assetserver/ (although
> > there is no usable code just yet).
> >
> >
> >
> > A large benefit that you gain from bringing the asset/inventory/etc
> > servers out from behind the simulator is allowing content creators to
> > manage their own assets, and stop binding end users to a single
> > grid-provided asset service. Offloading >80% of the traffic from the
> > simulator is just a side benefit.
> >
> >
> >
> > John
> >
> >
> >
> > *From:* opensim-dev-bounces at lists.berlios.de
> > [mailto:opensim-dev-bounces at lists.berlios.de] *On Behalf Of *Stefan
> > Andersson
> > *Sent:* Thursday, October 30, 2008 2:23 PM
> > *To:* opensim-dev at lists.berlios.de
> > *Subject:* Re: [Opensim-dev] OSGrid <-> UCIGrid
> >
> >
> >
> > I've been meaning to write a post for a very long time now. It's in
> my
> > draft folder. Just not getting it finished.
> >
> > First Step:
> > Just wanted you all to consider what would happen if we, on
> > ExpectAvatar sent some aux info like 'home user server url', 'home
> asset
> > server url' and 'home inventory server url' to be attached to the
> > ScenePresence, and had all communications interactions use those
> > provided urls.
> >
> > What I'm saying is, that the region could accept any avatar in the
> form
> > of an authenticated and authorized UUID only, so - "grid" would
> become
> > meaningless and "intergrid" becomes a moot issue - all regions would
> > always expect all clients to come from all different
> > user/asset/inventory servers. The authorization aspect of the "grid"
> > would then be a question of service trust, regions clustered under
> one
> > governing entity implementing its own trust schemes. One basic trust
> > scheme would probably be https.
> >
> > Next Step:
> > Consider then, if you will, if the "home" configuration would simply
> be
> > a function of a login to your own "home" login server, or simply as a
> > function of a modified viewer, hence the viewer would send preffered
> > service url's on login.
> >
> > Hey Presto, 3D Web for real. It's not that far away, even given the
> > current architecture.
> >
> > Best regards,
> > Stefan Andersson
> > Tribal Media AB
> >
> > Join the 3d web revolution : http://tribalnet.se/
> >
> >
> > ---------------------------------------------------------------------
> ---
> >
> >
> >>  Date: Thu, 30 Oct 2008 18:34:21 +0000
> >>  From: jjustincc at googlemail.com
> >>  To: opensim-dev at lists.berlios.de
> >>  Subject: Re: [Opensim-dev] OSGrid <-> UCIGrid
> >>
> >>  Cristina Videira Lopes wrote:
> >>  > Justin Clark-Casey wrote:
> >>  >> Strong -1 on committing this code directly to core at this
> stage.
> >>  >>
> >>  >> Charles, I strongly believe it would be better for us to see
> this
> > mature a little as an external module first, rather
> >>  >> than committing code directly to core. Please could we hold off
> at
> > least until the code has reached some level of
> >>  >> maturity, at which point we can have a discussion about what we
> > want to do.
> >>  >>
> >>  > +1 on Justin's -1 :-)
> >>  > There's no way I would propose the code as is today for a core
> patch;
> >>  > there's a lot stuff that is still loose.
> >>  > But I hope people will want the hypergrid model enough that the
> >>  > extensions will be delivered on the same "package" as the core,
> soon.
> >>  > And I hope there are volunteers from the core developers to help
> bring
> >>  > this up to speed!
> >>
> >>  Cool, thanks Cristina, glad to know that we're on the same
> wavelength :)
> >>
> >>  I'm sure there will be interest from core developers - there has
> been
> > occasional conversation about looking at
> >>  alternative ways of doing things. But again, kudos for actually
> doing
> > something - rough running code is always better
> >>  than talk :)
> >>
> >>  I'm quite keen myself but unfortunately more prosaic OpenSim server
> > bugs keep hitting me in the face in such a way that
> >>  I need to fix them for one reason or another.
> >>
> >>  >
> >>  >> There is also an argument that such modules should eventually be
> > outside the core anyway. The OGP modules we have are
> >>  >> in there because our region infrastructure module isn't advanced
> > enough to make it easy to host these outside of core.
> >>  >> This is something we should address (either having some protocol
> > modules in or having them all out).
> >>  >>
> >>  > +1 on that too. The hypergrid extension would be even simpler
> than what
> >>  > already is if only I could define externally what the comm module
> is. I
> >>  > suspect OGP suffers from the same problem.
> >>  >
> >>  >> That's not to say that this isn't very interesting work,
> Cristina.
> > Does the code fit into the module structure?
> >>  >>
> >>  > Yes. As I said, the only weirdness comes because I can't spec the
> comms
> >>  > module. If you change that, it will be a charm (modulo some
> visibility
> >>  > changes here and there).
> >>
> >>  Yep, apologies for not reading your previous e-mail carefully
> enough.
> > When I get a chance, I'll see if I can look at
> >>  your code and change the structure such that things are easier in
> this
> > respect (unless someone else does it first). Of
> >>  course, a patch to do such a thing is one that would be very
> welcome
> > and quickly applied too.
> >>
> >>  >> I had thoughts along similar lines for distributed grids.
> >>  >>
> >>  >>
> > http://justincc.wordpress.com/2008/08/15/could-there-be-a-future-
> without-big-grids/
> >>  >>
> >>  >> but I never actually implemented anything = so fair do's to
> > Cristina. Also, my thoughts were to conduct everything
> >>  >> client side.
> >>  >>
> >>  >> The problem does some with asset and inventory and routing this
> > information around. My thinking was that it would be
> >>  >> better if the client fetch this information directly rather than
> > via the sim, but this would require extensive (and
> >>  >> probably difficult) client changes.
> >>  >>
> >>  > A smarter client would make a lot of things a lot easier...
> >>
> >>  God yes. Sometimes I think the fact that it is GPL'd has been a
> > blessing in disguise - it allows us to implement a lot
> >>  of OpenSim without accompanying time spent thinking about the
> client.
> > But it seems that things are getting to the stage
> >>  where the restrictions are as painful as they are beneficial.
> >>
> >>  >
> >>  > _______________________________________________
> >>  > Opensim-dev mailing list
> >>  > Opensim-dev at lists.berlios.de
> >>  > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>  >
> >>
> >>
> >>  --
> >>  justincc
> >>  Justin Clark-Casey
> >>  http://justincc.wordpress.com
> >>  _______________________________________________
> >>  Opensim-dev mailing list
> >>  Opensim-dev at lists.berlios.de
> >>  https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> > ---------------------------------------------------------------------
> ---
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> --
> justincc
> Justin Clark-Casey
> http://justincc.wordpress.com
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev