[Opensim-dev] On solving Authentication and such

Diva Canto diva at metaverseink.com
Tue Feb 24 18:11:58 UTC 2009


There's a fine line to draw here, and if we go too far the immersion 
feeling will be affected. So the difficult thing in this approach will 
be to draw that line. It would be an interesting academic exercise to 
pull out ALL the features from the viewer except its 3D rendering 
engine-ness.

I started writing down an attempt at categorizing this, but I realized 
that we will never get consensus on the feeling of immersion. Our best 
option, on the OpenSim side, is to make it configurable at the services 
level and to leave it to the world builders to choose which features 
they want to serve via the 3D rendering engine viewer. The tradeoff 
being, the more features they allow the LL viewer to do, the less safely 
interoperable things will be because the LL viewer proxies things 
through the regions, therefore assuming the regions are to be trusted. 
In cases of worlds that don't want interoperability of any kind, or 
worlds that simply want the "trust domains" a-la Linden Lab, that is 
fine. For everything else (Hypergrid), regions are not to be trusted in 
general, and those extra 2D interfaces can be used instead.

The good thing is that if we do that separation, it shouldn't be hard 
for the Hippo devs, for example, to chop down the monolithic application 
and start integrating other more secure components.

In any case, here's a slightly more extended list of features to think 
about:

- Inventory
- Social network (groups, friends, etc)
- Admin tasks (estate/region/parcel permissions, bans, etc)
- Search
- IM
- Map
- Teleports
- Script editing
- Inter-user inworld interaction (inventory exchanges)
- ...

Stefan Andersson wrote:
> By the way,
>  
> I've been talking to some people lately around various viewer and 
> protocol issues, and I have come to realize that we are apparently 
> locked into the mindset of having the viewer being the 'community 
> application' - I would propose another frame of mind, separating 
> whatever should be done in 3D as a separate experience from what 
> should be done in 2D. Of course, they should interleave, but they 
> should not have to be implemented in the same codebase.
>  
> Huh? I hear you say.
>  
> To put it otherwise; the ideal setup would be a 3D rendering 
> surface optionally with 2D web surfaces superimposed on it. From 
> there, the 3D rendering surface should talk some real-time protocol to 
> a 3D scene streaming service (aka the region server) but the 2D web 
> surfaces should communicate with Web 2.0 services.
>  
> This would allow us to break the issues apart, and having various 
> competencies working on various domains, as well as letting the 
> application coders slice the cookie anyway they want.
>  
> So, what I'm saying is, in short: Let's start breaking stuff out of 
> the viewer context, and onto other user interfaces, like the web or 
> third-party admin tools.
>  
> I should have my preferred IM client, not my viewer.
>  
> I should have my (web-based?) inventory tool, not my viewer.
>  
> I should log in thru my social network, not my viewer.
>  
> I should transfer and administrate content thru aux means (web, file, 
> blog, e-mail, ftp, burn) not trhu the viewer.
>  
> et c.
>  
> Sure, we should always be able to do it thru clients that 
> provide adequate tools, but hey, let's break free of the centralized 
> monolith app thinking.
>  
> Ps, what's the difference with having windows on top of each others in 
> the 3D surface, and having windows on top of each others on the desktop?
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090224/4a0ddc00/attachment-0001.html>


More information about the Opensim-dev mailing list