[Opensim-dev] Distributed asset server proposal (was: RE: OSGrid <-> UCIGrid)
Toni Alatalo
antont at kyperjokki.fi
Fri Oct 31 22:51:18 UTC 2008
On Nov 1, 2008, at 12:29 AM, James Stallings II wrote:
> 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.
True, I did not actively remember that when writing the post. There is
no reason for the viewer version not to run on Linux and Mac though,
and some people have tried building it on Linux recently and progressed
somewhat, so perhaps they get that done too - dunno.
~Toni
> 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
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
More information about the Opensim-dev
mailing list