<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
By "access control" I mean object permissions, groups, etc.<br>
<br>
Diva Canto wrote:
<blockquote cite="mid:48E92CA9.8040407@metaverseink.com" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Wow, that's great to hear! When you say "we" is that opensim (did I
miss a few modules?!) or Tribal Media?<br>
Also, if you don't mind asking, are you able to use those other
frameworks as the basis for access control in opensim?<br>
<br>
Stefan Andersson wrote:
<blockquote cite="mid:BLU134-W40A9FA2E9AC84E60792301D53E0@phx.gbl"
type="cite">
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>Diva,<br>
<br>
at this moment in time, we've integrated OpenSim with Facebook,
DotNetNuke (.net community framework) as well as with proprietary
intranets and communities - basically by substituting, subclassing and
rewriting the OpenSim services, fetching and mapping various amounts of
community data.<br>
<br>
(Most often the user and login services, but also scene and grid
services for community-based on-demand content creation and allocation)<br>
<br>
Our experience is that OpenSim is encouragingly malleable, but also not
surprisingly, that things could be made even better.<br>
<br>
* Services could be defined in a common shared set of interfaces and
abstract classes that can be reused and implemented by non-opensim code
- this to enumerate for the application programmer what needs
implemented.<br>
* the functionality of the http handlers could be extracted out into
this common set so that they too can be re-used or subclassed.<br>
* the sl legacy 'avatar first and last as user id' and the
userId-Guid-centrism are two real issues. So far we (Tribal) have been
able to get around these by implementing seamless logins (the user does
not log in with avatar first and last, but thru supplying userId direct
thru url monikers or launcher apps) and various guid mapping schemes,
but it sure could have been easier if opensim supported a separate
userid concept, and that it was object oriented.<br>
* akin to the userId situation, most mature solutions have a 'Session'
concept that is not really reflected in OpenSim - we do have a
sessionId but one really would want to be able to subclass that to send
application-specific data with the session, and this session to be a
part of all backend transactions.<br>
<br>
I'm not sure what feedback you were really looking for, but this was a
quick write-up of things we've encountered so far. ;-)<br>
<br>
Best regards,<br>
Stefan Andersson<br>
Tribal Media AB<br>
<br>
Join the 3d web revolution : <a moz-do-not-send="true"
href="http://tribalnet.se/" target="_blank">http://tribalnet.se/</a><br>
<br>
<br>
<br>
<br>
<hr id="stopSpelling"> <br>
> Date: Sun, 5 Oct 2008 11:29:27 -0700<br>
> From: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:diva@metaverseink.com">diva@metaverseink.com</a><br>
> To: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
> Subject: [Opensim-dev] social network software<br>
> <br>
> Hi,<br>
> <br>
> Is anyone experimenting with combining social network software
(e.g. <br>
> <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://elgg.org/">http://elgg.org/</a>) and opensim, as an
alternative to the built-in
social <br>
> features of SL? Is there any fundamental incompatibility in doing
that? <br>
> (I'm thinking the user base being part of opensim may be a
problematic <br>
> overlap; or maybe not. I'm also thinking elgg's GPL2 license may
be <br>
> problematic; or maybe not) If there are no fundamental problems,
could <br>
> that be used as the basis for access control etc.?<br>
> <br>
> The idea would be to have all this user/social management as a
separate <br>
> component, possibly running on a separate server, and write only
the <br>
> code for accessing the social network server over the web whenever
<br>
> necessary. The interface for people to manage their info (friends,
<br>
> groups, etc) would have to be via web browser, instead of LL
viewer.<br>
> <br>
> Any thoughts?<br>
> <br>
> Crista<br>
> <br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br>
<pre wrap=""><hr size="4" width="90%">
_______________________________________________
Opensim-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>