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.<br><br>Cheers<br><br><div class="gmail_quote">On Fri, Oct 31, 2008 at 5:14 PM, Toni Alatalo <span dir="ltr"><<a href="mailto:antont@kyperjokki.fi">antont@kyperjokki.fi</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Oct 31, 2008, at 3:14 AM, Frisby, Adam wrote:<br>
<br>
> It would be nice if we could get the viewer to download the assets it<br>
> needs directly too rather than route them via the simulator. But of<br>
> course, protocol changes and LL is always fun.<br>
<br>
</div>Well, as you (all) know RealXtend is also doing protocol changes and<br>
maintaining and developing a version of the SL viewer that is changed<br>
and extended for more distributed stuff, and they might well be<br>
committed to support this kind of asset servers (iirc it's in the<br>
roadmap, and in a way implemented too for the avatars at least?). I<br>
don't mean to hijack this thread nor the list in general for a big<br>
debate on client development issues, but just want to point out that<br>
team and client version as a relatively realistic possibility for<br>
getting this soon.<br>
<br>
So the proposal is there, and the plan for current SL compatibility, so<br>
Rex client team can also take a look at the proposal and if the<br>
protocol is agreed on, they may implement it based on the spec, anyone<br>
can use it (without looking at the code ;), and there are no<br>
contamination issues. If this happens people can use the LL version of<br>
the viewer via the simulator workaround, but also the version that<br>
connects directly to asset servers, at least for testing.<br>
<br>
I'm afraid there may be an implementation level caveat, though: AFAIK<br>
the Rex viewer has SL compatibility so that the LL viewer is there<br>
basically unmodified, and used when connecting to SL or a vanilla<br>
OpenSim. That is, then the LL renderer is used, and I guess an<br>
unmodified version of the SL protocol too. Only in 'rex mode' the Ogre<br>
renderer is used, and I guess only then the rx protocol extensions<br>
(like using a separate authentication server, avatar/asset servers<br>
etc). This is a guess based on how I've seen it work and what I've<br>
heard about it, haven't looked at the code (only worked on the server<br>
side last winter) nor discussed this issue specifically.<br>
<br>
So it can be that it is not most straightforward to have a mode in the<br>
Rex viewer that would work with otherwise vanilla OpenSim, meaning SL<br>
compatibility, but that could use asset servers directly. But I may be<br>
also wrong there and perhaps that kind of extension could be easily<br>
added without the others (even though the original codebase and hence<br>
the extensions are reportedly quite a spaghetti at places..). Perhaps<br>
even the existing asset fetching stuff is there already in a modular<br>
enough way that it could be enabled for this as well. I hope they'll<br>
take a look at it at least, probably a good idea to discuss it more on<br>
the rex developers list, and then return here if there's some result<br>
(am supposing Jani or Mikko or someone has already picked this up from<br>
here :)<br>
<br>
Certainly I imagine places like Intel can also spare some programmer<br>
(who doesn't need to touch the opensim side..) to do client changes,<br>
dunno if that is the plan to be able to test this quickly, but as the<br>
Rex client guys have already 1 year of full time experience from making<br>
similar changes to the LL viewer and are committed to maintain that<br>
version etc. was thinking it might be worth a shot.<br>
<br>
> Adam<br>
<font color="#888888"><br>
~Toni<br>
</font>P.S. i'm not working with nor officially affiliated with realxtend<br>
right now, was just thinking about this based on what know from earlier<br>
and what hope would happen<br>
<div><div></div><div class="Wj3C7c"><br>
> From: <a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a><br>
> [mailto:<a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a>] On Behalf Of Hurliman,<br>
> John<br>
> Sent: Thursday, 30 October 2008 5:30 PM<br>
> To: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
> Subject: [Opensim-dev] Distributed asset server proposal (was: RE:<br>
> OSGrid <-> UCIGrid)<br>
> <br>
> This ties in closely with the asset server proposal we've been<br>
> brainstorming at Intel. The current version of the proposal is at<br>
> <a href="http://opensimulator.org/wiki/AssetServerProposal" target="_blank">http://opensimulator.org/wiki/AssetServerProposal</a> and the project<br>
> lives at <a href="http://forge.opensimulator.org/gf/project/assetserver/" target="_blank">http://forge.opensimulator.org/gf/project/assetserver/</a><br>
> (although there is no usable code just yet).<br>
> <br>
> A large benefit that you gain from bringing the asset/inventory/etc<br>
> servers out from behind the simulator is allowing content creators to<br>
> manage their own assets, and stop binding end users to a single<br>
> grid-provided asset service. Offloading >80% of the traffic from the<br>
> simulator is just a side benefit.<br>
> <br>
> John<br>
> <br>
> From: <a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a><br>
> [mailto:<a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a>] On Behalf Of Stefan<br>
> Andersson<br>
> Sent: Thursday, October 30, 2008 2:23 PM<br>
> To: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
> Subject: Re: [Opensim-dev] OSGrid <-> UCIGrid<br>
> <br>
><br>
> I've been meaning to write a post for a very long time now. It's in my<br>
> draft folder. Just not getting it finished.<br>
> <br>
> First Step:<br>
> Just wanted you all to consider what would happen if we, on<br>
> ExpectAvatar sent some aux info like 'home user server url', 'home<br>
> asset server url' and 'home inventory server url' to be attached to<br>
> the ScenePresence, and had all communications interactions use those<br>
> provided urls.<br>
> <br>
> What I'm saying is, that the region could accept any avatar in the<br>
> form of an authenticated and authorized UUID only, so - "grid" would<br>
> become meaningless and "intergrid" becomes a moot issue - all regions<br>
> would always expect all clients to come from all different<br>
> user/asset/inventory servers. The authorization aspect of the "grid"<br>
> would then be a question of service trust, regions clustered under one<br>
> governing entity implementing its own trust schemes. One basic trust<br>
> scheme would probably be https.<br>
> <br>
> Next Step:<br>
> Consider then, if you will, if the "home" configuration would simply<br>
> be a function of a login to your own "home" login server, or simply as<br>
> a function of a modified viewer, hence the viewer would send preffered<br>
> service url's on login.<br>
> <br>
> Hey Presto, 3D Web for real. It's not that far away, even given the<br>
> current architecture.<br>
><br>
> Best regards,<br>
> Stefan Andersson<br>
> Tribal Media AB<br>
> <br>
> Join the 3d web revolution : <a href="http://tribalnet.se/" target="_blank">http://tribalnet.se/</a><br>
> <br>
><br>
><br>
><br>
><br>
> > Date: Thu, 30 Oct 2008 18:34:21 +0000<br>
> > From: <a href="mailto:jjustincc@googlemail.com">jjustincc@googlemail.com</a><br>
> > To: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
> > Subject: Re: [Opensim-dev] OSGrid <-> UCIGrid<br>
> ><br>
> > Cristina Videira Lopes wrote:<br>
> > > Justin Clark-Casey wrote:<br>
> > >> Strong -1 on committing this code directly to core at this stage.<br>
> > >><br>
> > >> Charles, I strongly believe it would be better for us to see<br>
> this mature a little as an external module first, rather<br>
> > >> than committing code directly to core. Please could we hold off<br>
> at least until the code has reached some level of<br>
> > >> maturity, at which point we can have a discussion about what we<br>
> want to do.<br>
> > >><br>
> > > +1 on Justin's -1 :-)<br>
> > > There's no way I would propose the code as is today for a core<br>
> patch;<br>
> > > there's a lot stuff that is still loose.<br>
> > > But I hope people will want the hypergrid model enough that the<br>
> > > extensions will be delivered on the same "package" as the core,<br>
> soon.<br>
> > > And I hope there are volunteers from the core developers to help<br>
> bring<br>
> > > this up to speed!<br>
> ><br>
> > Cool, thanks Cristina, glad to know that we're on the same<br>
> wavelength :)<br>
> ><br>
> > I'm sure there will be interest from core developers - there has<br>
> been occasional conversation about looking at<br>
> > alternative ways of doing things. But again, kudos for actually<br>
> doing something - rough running code is always better<br>
> > than talk :)<br>
> ><br>
> > I'm quite keen myself but unfortunately more prosaic OpenSim server<br>
> bugs keep hitting me in the face in such a way that<br>
> > I need to fix them for one reason or another.<br>
> ><br>
> > ><br>
> > >> There is also an argument that such modules should eventually be<br>
> outside the core anyway. The OGP modules we have are<br>
> > >> in there because our region infrastructure module isn't advanced<br>
> enough to make it easy to host these outside of core.<br>
> > >> This is something we should address (either having some protocol<br>
> modules in or having them all out).<br>
> > >><br>
> > > +1 on that too. The hypergrid extension would be even simpler<br>
> than what<br>
> > > already is if only I could define externally what the comm module<br>
> is. I<br>
> > > suspect OGP suffers from the same problem.<br>
> > ><br>
> > >> That's not to say that this isn't very interesting work,<br>
> Cristina. Does the code fit into the module structure?<br>
> > >><br>
> > > Yes. As I said, the only weirdness comes because I can't spec the<br>
> comms<br>
> > > module. If you change that, it will be a charm (modulo some<br>
> visibility<br>
> > > changes here and there).<br>
> ><br>
> > Yep, apologies for not reading your previous e-mail carefully<br>
> enough. When I get a chance, I'll see if I can look at<br>
> > your code and change the structure such that things are easier in<br>
> this respect (unless someone else does it first). Of<br>
> > course, a patch to do such a thing is one that would be very<br>
> welcome and quickly applied too.<br>
> ><br>
> > >> I had thoughts along similar lines for distributed grids.<br>
> > >><br>
> > >><br>
> <a href="http://justincc.wordpress.com/2008/08/15/could-there-be-a-future-" target="_blank">http://justincc.wordpress.com/2008/08/15/could-there-be-a-future-</a><br>
> without-big-grids/<br>
> > >><br>
> > >> but I never actually implemented anything = so fair do's to<br>
> Cristina. Also, my thoughts were to conduct everything<br>
> > >> client side.<br>
> > >><br>
> > >> The problem does some with asset and inventory and routing this<br>
> information around. My thinking was that it would be<br>
> > >> better if the client fetch this information directly rather than<br>
> via the sim, but this would require extensive (and<br>
> > >> probably difficult) client changes.<br>
> > >><br>
> > > A smarter client would make a lot of things a lot easier...<br>
> ><br>
> > God yes. Sometimes I think the fact that it is GPL'd has been a<br>
> blessing in disguise - it allows us to implement a lot<br>
> > of OpenSim without accompanying time spent thinking about the<br>
> client. But it seems that things are getting to the stage<br>
> > where the restrictions are as painful as they are beneficial.<br>
> ><br>
> > ><br>
> > > _______________________________________________<br>
> > > Opensim-dev mailing list<br>
> > > <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> > > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
> > ><br>
> ><br>
> ><br>
> > --<br>
> > justincc<br>
> > Justin Clark-Casey<br>
> > <a href="http://justincc.wordpress.com" target="_blank">http://justincc.wordpress.com</a><br>
> > _______________________________________________<br>
> > Opensim-dev mailing list<br>
> > <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>===================================<br>The wind<br>scours the earth for prayers<br>The night obscures them<br><br><a href="http://osgrid.org">http://osgrid.org</a><br>
<a href="http://del.icio.us/SPQR">http://del.icio.us/SPQR</a><br><a href="http://twitter.com/jstallings2">http://twitter.com/jstallings2</a><br><a href="http://www.linkedin.com/pub/5/770/a49">http://www.linkedin.com/pub/5/770/a49</a><br>