[Opensim-dev] Distributed asset server proposal (was: RE: OSGrid <-> UCIGrid)

James Stallings II james.stallings at gmail.com
Fri Oct 31 22:29:38 UTC 2008 

There's the whole problem with rexx that there is no linux or mac osx
support. That leaves a good many devs and operators out of that picture. Not
a viable option IMHO.

Cheers

On Fri, Oct 31, 2008 at 5:14 PM, Toni Alatalo <antont at kyperjokki.fi> wrote:

> On Oct 31, 2008, at 3:14 AM, Frisby, Adam wrote:
>
> > 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.
>
> Well, as you (all) know RealXtend is also doing protocol changes and
> maintaining and developing a version of the SL viewer that is changed
> and extended for more distributed stuff, and they might well be
> committed to support this kind of asset servers (iirc it's in the
> roadmap, and in a way implemented too for the avatars at least?). I
> don't mean to hijack this thread nor the list in general for a big
> debate on client development issues, but just want to point out that
> team and client version as a relatively realistic possibility for
> getting this soon.
>
> So the proposal is there, and the plan for current SL compatibility, so
> Rex client team can also take a look at the proposal and if the
> protocol is agreed on, they may implement it based on the spec, anyone
> can use it (without looking at the code ;), and there are no
> contamination issues. If this happens people can use the LL version of
> the viewer via the simulator workaround, but also the version that
> connects directly to asset servers, at least for testing.
>
> I'm afraid there may be an implementation level caveat, though: AFAIK
> the Rex viewer has SL compatibility so that the LL viewer is there
> basically unmodified, and used when connecting to SL or a vanilla
> OpenSim. That is, then the LL renderer is used, and I guess an
> unmodified version of the SL protocol too. Only in 'rex mode' the Ogre
> renderer is used, and I guess only then the rx protocol extensions
> (like using a separate authentication server, avatar/asset servers
> etc). This is a guess based on how I've seen it work and what I've
> heard about it, haven't looked at the code (only worked on the server
> side last winter) nor discussed this issue specifically.
>
> So it can be that it is not most straightforward to have a mode in the
> Rex viewer that would work with otherwise vanilla OpenSim, meaning SL
> compatibility, but that could use asset servers directly. But I may be
> also wrong there and perhaps that kind of extension could be easily
> added without the others (even though the original codebase and hence
> the extensions are reportedly quite a spaghetti at places..). Perhaps
> even the existing asset fetching stuff is there already in a modular
> enough way that it could be enabled for this as well. I hope they'll
> take a look at it at least, probably a good idea to discuss it more on
> the rex developers list, and then return here if there's some result
> (am supposing Jani or Mikko or someone has already picked this up from
> here :)
>
> Certainly I imagine places like Intel can also spare some programmer
> (who doesn't need to touch the opensim side..) to do client changes,
> dunno if that is the plan to be able to test this quickly, but as the
> Rex client guys have already 1 year of full time experience from making
> similar changes to the LL viewer and are committed to maintain that
> version etc. was thinking it might be worth a shot.
>
> > Adam
>
> ~Toni
> P.S. i'm not working with nor officially affiliated with realxtend
> right now, was just thinking about this based on what know from earlier
> and what hope would happen
>
> > 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
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>



-- 
===================================
The wind
scours the earth for prayers
The night obscures them

http://osgrid.org
http://del.icio.us/SPQR
http://twitter.com/jstallings2
http://www.linkedin.com/pub/5/770/a49
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081031/5fcacbce/attachment-0001.html>

More information about the Opensim-dev mailing list