<!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">
It may be annoying for experimentation, but it is possible that Linden
Lab (r)/(tm) is doing this to start addressing the security issues of
interoperability. Once we have (a) clients running in untrusted
servers; and (b) servers running code sent by untrusted clients, all
sorts of bad stuff can happen. Or it may be that they're just doing it
to prevent LL viewer users from experiencing non-LL servers. Who knows.<br>
<br>
But the security issues are valid, whether that's LL's motivation or
not. It all boils down to trust. One of these days opensim will have to
start walking that slippery alley, and come up with a trust API for
servers and clients. I think we have an opportunity to do this right.
Trust is a people thing. Unlike the web, where people don't exist (only
ghostly agents defined by IPs and, maybe, cookies), we have people
here. So the policies can be specified at users' level. LL's static API
checking seems a bit odd. It may make more sense to ask the user
whether she trusts the region server.<br>
<br>
As for Stefan's idea of an aux client editor for code: have you tried
Visual C#? It's great! hehe ;-)<br>
Seriously, my group here has been experimenting with all sorts of
completely different clients to get/post all sorts of different things
from/into the world. Once the Http server was made accessible to region
modules, there's no limit to what can be done, really... But for this
to scale beyond experimentation, we need to figure out trust.<br>
<br>
<br>
Stefan Andersson wrote:
<blockquote cite="mid:BLU134-W46107D601414C40615FBBCD5470@phx.gbl"
type="cite">
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>You know, we have options here;<br>
<br>
how would the perfect developer environment for opensim with
a connected viewer look like?<br>
<br>
I definitively could see a tighter coupling to something like a file
system or a revisioning-like system, so that I could just save a file,
and that would trigger an recompilation and reload of that file as a
script.<br>
<br>
that would go excellent with being able to diff and subversion code
files; not to mention the ability to use other environments that the
built-in editor to work with large codebases (hell, why wouldn't dll's
just get sucked up and connected as well, if there's an IScript in
them?)<br>
<br>
Or, should there just be an aux client editor that could post ascript
like the client does?<br>
<br>
Just trying to get ye olde oute-of-the-boxe thinking going.<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="EC_stopSpelling">
<br>
Date: Fri, 26 Sep 2008 10:00:10 +0200<br>
From: <a class="moz-txt-link-abbreviated" href="mailto:DrScofield@xyzzyxyzzy.net">DrScofield@xyzzyxyzzy.net</a><br>
To: <a class="moz-txt-link-abbreviated" href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a>; <a class="moz-txt-link-abbreviated" href="mailto:opensim-users@lists.berlios.de">opensim-users@lists.berlios.de</a><br>
Subject: [Opensim-users] heads up: recent secondlife client versions
don't support OSSL functions<br>
<br>
<meta content="Microsoft SafeHTML" name="Generator">
having just wasted most of a day on trying to figure out why OSSL
functions such as osSetDynamicTextureData and friends were returning an
LSL compile error (ERROR: name not in scope) i thought i'd report back
on my findings:<br>
<br>
<ul>
<li>OSSL functions (inspite of the heavy changes in the scripting
subsystem in recent days) are working just fine (provided you enabled
them as documented in OpenSim.ini.example)</li>
<li>recent LindenLab(tm)/(r) provided secondlife clients (certainly
the 1.21 series) are apparently no longer relying on the grid to vet
the script and the functions it calls, but instead seem to check all
function calls against</li>
<ul>
<li>list of known LSL function</li>
<li>list of functions you have defined in your script</li>
</ul>
<ul>
<li>anything not found on those lists is flagged as "not in scope"</li>
</ul>
</ul>
once i switched to hippo viewer <a moz-do-not-send="true"
href="http://forge.opensimulator.org/gf/project/opensim-viewer/"
target="_blank">(http://forge.opensimulator.org/gf/project/opensim-viewer/)</a>
everything was fine.<br>
<br>
cheers,<br>
dr scofield<br>
<pre class="EC_moz-signature">--
dr dirk husemann ---- virtual worlds research ---- ibm zurich research lab
SL: dr scofield ---- <a moz-do-not-send="true"
class="EC_moz-txt-link-abbreviated"
href="mailto:drscofield@xyzzyxyzzy.net">drscofield@xyzzyxyzzy.net</a> ---- <a
moz-do-not-send="true" class="EC_moz-txt-link-freetext"
href="http://xyzzyxyzzy.net/" target="_blank">http://xyzzyxyzzy.net/</a>
RL: <a moz-do-not-send="true" class="EC_moz-txt-link-abbreviated"
href="mailto:hud@zurich.ibm.com">hud@zurich.ibm.com</a> - +41 44 724 8573 - <a
moz-do-not-send="true" class="EC_moz-txt-link-freetext"
href="http://www.zurich.ibm.com/%7Ehud/" target="_blank">http://www.zurich.ibm.com/~hud/</a>
</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Opensim-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-users@lists.berlios.de">Opensim-users@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-users">https://lists.berlios.de/mailman/listinfo/opensim-users</a>
</pre>
</blockquote>
<br>
</body>
</html>