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@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
