Re: [opensource-dev] step by step guide to compiling snowglobe

[Carlo Wood]

On Thu, Feb 18, 2010 at 01:06:54PM -0600, Jonathan Irvin wrote:
> As far as SnowGlobe goes, I wish it was more modular like linux goes.  To 
> where
> we can add packages or remove them from the base install to grant us this or
> that.  When one module gets updated we can just download it as needed.

I would like that too, but... as long as "we" want to stay in sync with the
"official" viewer of Linden Lab (or they with us), we cannot make any large
changes.

I consider this a very bad thing personally, so I'm not in favour of staying
in sync. I think Snowglobe would benefit to let go of trying to be merge-able
with the "official viewer" and start to really allow BIG changes.

> AlsoHey Linden Labs, when are we going to put Second Life in linux package
> format so we can just link to your repo and have us be able to install and
> upgrade from our respective package managers, i.e Yum & Apt-Get?

Actually, that is the task of linux distributors. For example, in the case
of debian, of volunteers that become "package manager" for a specific packet.
In our case, that would be Robin Cornelius. It's not fair to look at Linden
Lab for making linux packages for every distribution out there.

However, they *should* listen to package managers with some kind of priority.
If those request a bug fix that only LL can fix, then that is backed up by
a very large number of users and should get high priority.

-- 
Carlo Wood 
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Carlo Wood]

On Thu, Feb 18, 2010 at 01:31:43PM -0500, kow wrote:
> I for one agree with Q.

You're not really stating what you agree with here... but lets assume
you mean that:

- It's ok that nothing was communicated on this list about anything
  prior to some decisions made by LL about client-side scripting.

- People shouldn't whine or flame about not being taken seriously
  when we tell them what has been decided behind closed doors.

> The biggest complaints come from the most insignificant people.

That is a flame, and pretty personal one too.
But I'll try to read between the lines and make something of it;
you probably mean that you didn't see any comments yet from the
most active opensource coders of snowglobe yet.

Those people are intelligent, of course, and have had close(r)
communication with a handful of Lindens than the others, getting
to know them a lot better than the average office hour visitor.
Those people understand that the decisions being communicated
by THOSE Lindens are not the decision of those Lindens personally
(at least, I hope not, or they DO deserve the flames). Most
snowglobe assigned Lindens have very little influence in the whole.
They are just coders with a big boss that demands apparently
pretty stricty that they cannot talk about things.

I'm sure that most Lindens that we have contact with are just
like you and me, they just got hired by LL and are now being
frustrated by the tension that LL policy as a whole is creating
between the entity Linden Lab and the "open source community"
that they attracted to work on snowglobe.

I think that most of the really active coders think that their
personal relationship with their fellow hackers inside Linden
Lab is more important than venting their frustration on a public
mailinglist KNOWING that it is going to be useless, since that
decision has indeed already been made (they ARE going to use
mono) and even the Lindens that we CAN communicate with can't
do anything about it.

If anything, I admite Q for not falling back to "Sorry, but
it's not my decision to make", but despite the pressure from
the opensource community keeps acting as-if Linden Lab has
one single mind and direction (which no doubt is the policy
of LL management).

> If LL prioritized development based on the 
> complaints in this mailing list, they would be rewriting SL for Linux 
> using GTK and maintaining a dozen branches for ever popular flavour of 
> unix. But then we'd just be playing a thinly veiled OpenCroquet.

When I read such proposals I didn't take them seriously either. 
And perhaps it IS necessary to play parent and take the decision
yourself in order to protect your kid; but it can be done better
by at least first have an open discussion (on this mailinglist)
about the pros and cons of whatever BIG decision (like using
mono). And then I mean ***NOT*** to ask for "feedback" and then
sit back and read everything and then make your decision, Babbage.
I mean, to actively participate in the discussion and try to
convince people with logical arguments and having an open mind
for ideas that are not your own. Then, in the end, I guess someone
"authoritive" has to make the final decision (because in most
cases not everyone will agree with the same), which could be done
in a form like:

- We had a meeting today with u, v, w, x, y, z and q Linden, and
  after careful consideration we decided to go for mono for
  the following reasons:
  * point 1
  * point 2
  * it's the only thing we really have the expertise for in-house
  * Foobar had the argument this and that, but blah blah.
  * Carlo was right, but we felt that over all the advantages of
mono weight more heavily than his proposal, as we already
discussed on the list
  * and so on.

> Instead of making accusations and generating pages upon pages of 
> arguments based on hearsay, why not ask a well thought out question that 
> a developer can answer with a simple yes or no? I'd much rather Q and 
> his coworkers spent time developing cool things than entertaining your 
> pointless nerd rage about Mono.

I applaud your speech, and again, I agree that not any of these
Lindens is personally responsible, so they don't deserve any flames.

However, on this route that LL as a whole is taking now, the only
logical result would be that Snowglobe splits off and becomes a
TRUE opensource community driven project. And that would mean,
at least in the eyes of Linden Lab, that the whole opensource
project has failed.

-- 
Carlo Wood 
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Carlo Wood]

On Fri, Feb 19, 2010 at 02:17:17PM +0100, Carlo Wood wrote:
> If anything, I admite Q for not falling back to "Sorry, but

admire*

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Morgaine]

Ricky, I agree with you, there are indeed two different requirements being
discussed here, and confusing them as a single requirement can never yield a
satisfactory result.  Indeed, Dahlia and I were discussing that same thing
yesterday, 
hereand
here
.

I would avoid your terminology though, because both kinds of script
application employ "client-side scripting", both types create dynamic
"extensions",  and both types can be implemented as "plugins" --- your terms
directly describe the technologies that can be used in both types of
application and don't distinguish between the two differing requirements.
It would just add to the confusion.

Instead, let's call them what they are:  TRUSTED APPS, and UNTRUSTED APPS.

(We can happily replace "apps/applications" with "scripts", "programs",
"extensions", "plugins", "code", and many other words, while still retaining
exactly the desired meaning and intent --- the key differentiator is
"trusted" versus "untrusted".)

The big problem we have here at the moment though is that *apparently*,
Lindens want to support *untrusted* apps ONLY, as evidenced by the mandatory
sandbox and mandatory use of Mono.  If so, this inherently means that all
the myriad uses of *trusted* client-side scripting (many more of them than
untrusted) are left out in the cold.  LL is refusing to even discuss this
twofold requirement with us, it seems, although Q may well reconsider and
rejoin the discussion here today.  I hope so, because yesterday's response
indicated no desire to cooperate with the mailing list on this, which would
be a disaster for all.

It is very unfortunate that we have to guess at Linden's intentions in this
area instead of being able to work openly with them on requirements and core
design.  I am still hopeful though.  Lindens have committed to working with
the community on the open source client, and unless that happens visibly and
honestly, community support is going to evaporate and move to other
clients.  They probably realize this, so I'm hopeful that openness will
prevail at LL.

The present issue is a test of this, and a massively important test because
client-side scripting (of both types) is such an empowering tool for the
open source community.  We *need* that open cooperation, just as the company
needs it, so fingers crossed.

(I miss Rob massively!  A champion for open source at the Lab is so badly
needed.)


Morgaine.





=

On Fri, Feb 19, 2010 at 7:16 AM, Ricky  wrote:

> I suspect that there are two things being discussed here without
> distinction: Client scripting, and client extensions.  Confusing the two is
> easy.
>
> Client-side scripting SHOULD be sandboxed, and in a controlled set of
> languages.  For a close example think of javascript in web browsers.
>
> Client extensions, or alternatively named as "plugins", would be modules
> that can be plugged in and out of the client and run /as if/ they were a
> part of the client.  Think of browser add-ons/plugins/extensions.
>
> Client side scripts could (read might be, could possibly, needs further
> thought, etc.) be given permission to be loaded in by worn items
> automatically.  Other objects would likely need to request permission via a
> security warning.
>
> Client extensions would have to be downloaded and installed externally; not
> delivered in-world.  These would truly be programs on your computer, and
> should be treated as such.
>
> Just my thoughts hoping for a clearer discussion.
>
> Ricky
> Cron Stardust
>
> On Thu, Feb 18, 2010 at 2:27 PM, Morgaine 
> wrote:
>
>> On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble 
>> wrote:
>>
>>> To me, an environment such as SL or the web in general tend to attract a
>>> few malicious developers, or more so, companies and individuals who are
>>> interested in collecting personal data and usage patterns. I'd prefer some
>>> level of control over what they can access without needing to understand the
>>> source code of any scripted extensions (if indeed source was available).
>>>
>>>
>> Dahlia, I agree with part of that, to the extent where it applies:
>>
>> The "malicious users" argument presupposes that scripts come from 3rd
>> parties, some of whom are malicious.  When people write their own scripts,
>> which is very common in this opensource-dev community, they are not
>> malicious 3rd parties, and they do not generally want to be treated as such.
>>
>> Quite the opposite, they want all the power that scripting on their local
>> platform can give them.  Therefore the "malicious users" argument applies
>> only to a subset of scripts, the downloaded ones, and it is perfectly valid
>> there.  However, it does not apply to one's own scripts, nor to any other
>> power-users' scripts that one wishes to trust.
>>
>> This leads directly to a rather fundamenta

Re: [opensource-dev] Client-side scripting in Snowglobe

[Carlo Wood]

On Fri, Feb 19, 2010 at 01:30:28PM +, Morgaine wrote:
> I would avoid your terminology though, because both kinds of script 
> application
> employ "client-side scripting", both types create dynamic "extensions",  and
> both types can be implemented as "plugins" --- your terms directly describe 
> the
> technologies that can be used in both types of application and don't
> distinguish between the two differing requirements.  It would just add to the
> confusion.

Plugins are inheritly unsafe and will have access to anything a normal
process has. If client-side scripting is going to be provided on a plugin
with the same access to the system, then it's still a plugin.

Hence, I see no problem talking about "plugins" for "trusted" applications
and not even mention scripting in that case (for now).

Then we can reserve the word client-side-scripting for third party /
downloaded scripts.

-- 
Carlo Wood 
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Morgaine]

You can make a plugin part of the process space of its host app or a
separate process, it's up to you.  The "same process space" architecture is
merely the simplest one, and so it's the most common, but now that we're in
the age of multicore, that is changing rapidly because it is so easy to
harness more cores with separate processes, and it avoids the many pitfalls
of concurrent thread programming with shared state.

When separate processes are used for plugins (typically communicating with
the host via socket), they can be either totally disjoint or they can share
one or memory segments, the term is quite generic.  When we were designing
the client-side scripting plugins for Imprudence, we used the separate
process space 
architecture.
  LL uses the same approach in their media plugins (Plugin-API), they're
external to the host viewer as well.  This is going to become a very common
architecture for plugins, in part because of the strong safety and security
of process separation.  Internal or external is really an implementation
detail for plugins.

Since plugin systems of both types are in common use, the term "plugin" is
not useful to us when differentiating between *trusted* scripts and *
untrusted* scripts.  (Sandboxes can be in internal memory space or external
process space too.)  At this stage we're just trying to raise a discussion
with Lindens about the two quite distinct requirements, trusted and
untrusted, both of which are extremely important and both of which need to
be supported.

Discussing the process design architecture will be highly interesting and
important too of course, but it's all rather academic if we can't get
Lindens to even discuss the requirements.  While I appreciate your earlier
suggestion that Snowglobe could go independent if community needs are not
met, I have not yet lost hope that Lindens will decide to work with the open
source community on client-side scripting.

It's only day #2 of this after all. :-)


Morgaine.




===

On Fri, Feb 19, 2010 at 1:50 PM, Carlo Wood  wrote:

> On Fri, Feb 19, 2010 at 01:30:28PM +, Morgaine wrote:
> > I would avoid your terminology though, because both kinds of script
> application
> > employ "client-side scripting", both types create dynamic "extensions",
>  and
> > both types can be implemented as "plugins" --- your terms directly
> describe the
> > technologies that can be used in both types of application and don't
> > distinguish between the two differing requirements.  It would just add to
> the
> > confusion.
>
> Plugins are inheritly unsafe and will have access to anything a normal
> process has. If client-side scripting is going to be provided on a plugin
> with the same access to the system, then it's still a plugin.
>
> Hence, I see no problem talking about "plugins" for "trusted" applications
> and not even mention scripting in that case (for now).
>
> Then we can reserve the word client-side-scripting for third party /
> downloaded scripts.
>
> --
> Carlo Wood 
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Morgaine]

Indeed Rob!

Lua is a brilliant language for adding scripting to existing applications
--- it's designed expressly for embedding and extending, it has a clean
syntax, it is linguistically very powerful, it is very tiny (the whole thing
can add under 100KB to your application), it can run sandboxed or not as
desired, and it is one of the fastest pure scripting languages currently
available, a lot faster than say Python.

It is no surprise then that game developers worldwide flocked to it in
droves, and now it's one of the most common scripting languages found
embedded in games.  WoW fans use it daily as an intrinsic part of their WoW
client, and a huge community has grown up around Lua-powered interfaces for
that game.

So yes, I'm with you on the importance of Lua for client-side scripting of
the viewer.

However, advocating Lua as the sole means of scripting viewers would be just
as bad a mistake as advocating C# or CLR-targetted languages only.  It would
support only one part of the scripting community directly, while
discriminating against everyone else.  This is not necessary.

Instead, defining a socket-based API interface would allow effectively any
language to be used for scripting the viewer, since virtually all languages
today have socket capabilities.  That would certainly include Lua and C# and
Python and Perl and Java and Clojure and C/C++ and ObjectiveC and Smalltalk,
to name a few languages that this community uses regularly.

The only thing that we would have to agree on would be the set of messages
that cross the socket interface, and the set of functions and callbacks that
the messages would engage in the viewer.  That's the kind of productive
technical discussion we could be having with Lindens, if their design
process for client-side scripting were open.  It needs to be.


Morgaine.





===

On Fri, Feb 19, 2010 at 5:24 AM, Rob Nelson wrote:

> B-B-But what about Lua, which has already been implemented in FlexLife
> (http://flexlife.nexisonline.net)? :(
>
> Fred Rookstown
> Lead Developer
>
> On Thu, 2010-02-18 at 12:42 +, Morgaine wrote:
> > I referred recently to Linden's internal project "Firefly" to add
> > client-side scripting to SL viewers.  This has been the topic of open
> > discussion at several Office Hours with Lindens in SL, but that
> > openness has not extended to many design details --- the Firefly
> > design process is not open to the community.  The only technical
> > details that are being disclosed about Firefly appear to be:
> >
> >   * "Scripts" are actually Mono assemblies, so that only languages
> > that compile to Mono will be allowed.
> >   * The programs run in a sandbox, which means that most platform
> > resources are not accessible to them.
> >
> > Please note that I quite like C# as a language, but the following
> > remarks are about Mono use in the SL viewer, only, where its tradeoffs
> > are poor.
> >
> > The first known detail about Firefly (mandatory Mono) is problematic
> > on several fronts:
> >  1. Only a tiny fraction of the world's applications, libraries
> > and languages work on Mono, so client-side scripting will be
> > unable to benefit from the huge mountain of resources
> > available on the Internet.  This is an extremely severe
> > limitation, and an unnecessary restriction in the context of
> > client-side viewer scripting.  If I want to use a
> > locally-installed package X from within my client-side script,
> > I should be able to.  What runs client-side should always be
> > our individual choice, not someone else's.
> >  2. Programmers want to write client-side scripts in the language
> > that they know best, because that always yields the fastest
> > progress and highest quality results.  There was a good
> > technical reason for forcing everyone to use LSL server-side,
> > but there is no technical reason to impose this requirement on
> > all client-side scripting.  It is counter-productive to force
> > CLR compatibility on client-side script developers when there
> > is a simple alternative:  define a socket-based viewer API for
> > client-side scripts instead, hence usable from any language.
> >  3. Mono runs poorly on Linux, so from being rock-solid on Linux
> > now, the LL-derived viewers will become second-rate on this
> > platform.
> >  4. The viewer is already extremely bloated and a memory hog.
> >  Adding a Mono dependency will compound that horribly.
> >  5. There is only one effective supplier of Mono:  Novell.  That
> > is a very bad situation to encourage and to support in the
> > viewer.
> >  6. Some parties identify other reasons for avoiding Mono in
> > general.  Without getting into that subject at all,
> >
> > The second known detail about Firefly (mandatory sandbox) is

Re: [opensource-dev] Client-side scripting in Snowglobe

[Morgaine]

Not forgetting Erlang, Ruby, LISP, Javascript, and Bourne shell of course.
:-)

But here's the fun one, for some value of "fun" ...  Someone would
undoubtedly write an LSL binding to the socket-based API too.  And however
much we screw up our noses at LSL, I have no doubt that a large number of SL
users who know no other language would be very happy to see it. :-)

Providing a socket-based interface to the viewer would be a hugely
all-embracing approach to client-side scripting, supporting everyone's
needs.  I think it deserves consideration.


Morgaine.




===

On Fri, Feb 19, 2010 at 3:23 PM, Morgaine wrote:

> Indeed Rob!
>
> Lua is a brilliant language for adding scripting to existing applications
> --- it's designed expressly for embedding and extending, it has a clean
> syntax, it is linguistically very powerful, it is very tiny (the whole thing
> can add under 100KB to your application), it can run sandboxed or not as
> desired, and it is one of the fastest pure scripting languages currently
> available, a lot faster than say Python.
>
> It is no surprise then that game developers worldwide flocked to it in
> droves, and now it's one of the most common scripting languages found
> embedded in games.  WoW fans use it daily as an intrinsic part of their WoW
> client, and a huge community has grown up around Lua-powered interfaces for
> that game.
>
> So yes, I'm with you on the importance of Lua for client-side scripting of
> the viewer.
>
> However, advocating Lua as the sole means of scripting viewers would be
> just as bad a mistake as advocating C# or CLR-targetted languages only.  It
> would support only one part of the scripting community directly, while
> discriminating against everyone else.  This is not necessary.
>
> Instead, defining a socket-based API interface would allow effectively any
> language to be used for scripting the viewer, since virtually all languages
> today have socket capabilities.  That would certainly include Lua and C# and
> Python and Perl and Java and Clojure and C/C++ and ObjectiveC and Smalltalk,
> to name a few languages that this community uses regularly.
>
> The only thing that we would have to agree on would be the set of messages
> that cross the socket interface, and the set of functions and callbacks that
> the messages would engage in the viewer.  That's the kind of productive
> technical discussion we could be having with Lindens, if their design
> process for client-side scripting were open.  It needs to be.
>
>
> Morgaine.
>
>
>
>
>
> ===
>
>
> On Fri, Feb 19, 2010 at 5:24 AM, Rob Nelson 
> wrote:
>
>> B-B-But what about Lua, which has already been implemented in FlexLife
>> (http://flexlife.nexisonline.net)? :(
>>
>> Fred Rookstown
>> Lead Developer
>>
>> On Thu, 2010-02-18 at 12:42 +, Morgaine wrote:
>> > I referred recently to Linden's internal project "Firefly" to add
>> > client-side scripting to SL viewers.  This has been the topic of open
>> > discussion at several Office Hours with Lindens in SL, but that
>> > openness has not extended to many design details --- the Firefly
>> > design process is not open to the community.  The only technical
>> > details that are being disclosed about Firefly appear to be:
>> >
>> >   * "Scripts" are actually Mono assemblies, so that only languages
>> > that compile to Mono will be allowed.
>> >   * The programs run in a sandbox, which means that most platform
>> > resources are not accessible to them.
>> >
>> > Please note that I quite like C# as a language, but the following
>> > remarks are about Mono use in the SL viewer, only, where its tradeoffs
>> > are poor.
>> >
>> > The first known detail about Firefly (mandatory Mono) is problematic
>> > on several fronts:
>> >  1. Only a tiny fraction of the world's applications, libraries
>> > and languages work on Mono, so client-side scripting will be
>> > unable to benefit from the huge mountain of resources
>> > available on the Internet.  This is an extremely severe
>> > limitation, and an unnecessary restriction in the context of
>> > client-side viewer scripting.  If I want to use a
>> > locally-installed package X from within my client-side script,
>> > I should be able to.  What runs client-side should always be
>> > our individual choice, not someone else's.
>> >  2. Programmers want to write client-side scripts in the language
>> > that they know best, because that always yields the fastest
>> > progress and highest quality results.  There was a good
>> > technical reason for forcing everyone to use LSL server-side,
>> > but there is no technical reason to impose this requirement on
>> > all client-side scripting.  It is counter-productive to force
>> > CLR compatibility on client-side script developers when there
>> > is a simple alternative:  def

Re: [opensource-dev] Client-side scripting in Snowglobe

[k\o\w]

RLVa, supports something like this, and can be found in most 3rd party 
viewers:

http://rlva.catznip.com/blog/
http://wiki.secondlife.com/wiki/RestrainedLifeAPI

On 2/19/2010 10:38 AM, Morgaine wrote:
Not forgetting Erlang, Ruby, LISP, Javascript, and Bourne shell of 
course. :-)


But here's the fun one, for some value of "fun" ...  Someone would 
undoubtedly write an LSL binding to the socket-based API too.  And 
however much we screw up our noses at LSL, I have no doubt that a 
large number of SL users who know no other language would be very 
happy to see it. :-)


Providing a socket-based interface to the viewer would be a hugely 
all-embracing approach to client-side scripting, supporting everyone's 
needs.  I think it deserves consideration.



Morgaine.




===

On Fri, Feb 19, 2010 at 3:23 PM, Morgaine 
> wrote:


Indeed Rob!

Lua is a brilliant language for adding scripting to existing
applications --- it's designed expressly for embedding and
extending, it has a clean syntax, it is linguistically very
powerful, it is very tiny (the whole thing can add under 100KB to
your application), it can run sandboxed or not as desired, and it
is one of the fastest pure scripting languages currently
available, a lot faster than say Python.

It is no surprise then that game developers worldwide flocked to
it in droves, and now it's one of the most common scripting
languages found embedded in games.  WoW fans use it daily as an
intrinsic part of their WoW client, and a huge community has grown
up around Lua-powered interfaces for that game.

So yes, I'm with you on the importance of Lua for client-side
scripting of the viewer.

However, advocating Lua as the sole means of scripting viewers
would be just as bad a mistake as advocating C# or CLR-targetted
languages only.  It would support only one part of the scripting
community directly, while discriminating against everyone else. 
This is not necessary.


Instead, defining a socket-based API interface would allow
effectively any language to be used for scripting the viewer,
since virtually all languages today have socket capabilities. 
That would certainly include Lua and C# and Python and Perl and

Java and Clojure and C/C++ and ObjectiveC and Smalltalk, to name a
few languages that this community uses regularly.

The only thing that we would have to agree on would be the set of
messages that cross the socket interface, and the set of functions
and callbacks that the messages would engage in the viewer. 
That's the kind of productive technical discussion we could be

having with Lindens, if their design process for client-side
scripting were open.  It needs to be.


Morgaine.





===


On Fri, Feb 19, 2010 at 5:24 AM, Rob Nelson
mailto:nexisentertainm...@gmail.com>> wrote:

B-B-But what about Lua, which has already been implemented in
FlexLife
(http://flexlife.nexisonline.net)? :(

Fred Rookstown
Lead Developer

On Thu, 2010-02-18 at 12:42 +, Morgaine wrote:
> I referred recently to Linden's internal project "Firefly"
to add
> client-side scripting to SL viewers.  This has been the
topic of open
> discussion at several Office Hours with Lindens in SL, but that
> openness has not extended to many design details --- the Firefly
> design process is not open to the community.  The only technical
> details that are being disclosed about Firefly appear to be:
>
>   * "Scripts" are actually Mono assemblies, so that only
languages
> that compile to Mono will be allowed.
>   * The programs run in a sandbox, which means that most
platform
> resources are not accessible to them.
>
> Please note that I quite like C# as a language, but the
following
> remarks are about Mono use in the SL viewer, only, where its
tradeoffs
> are poor.
>
> The first known detail about Firefly (mandatory Mono) is
problematic
> on several fronts:
>  1. Only a tiny fraction of the world's applications,
libraries
> and languages work on Mono, so client-side scripting
will be
> unable to benefit from the huge mountain of resources
> available on the Internet.  This is an extremely severe
> limitation, and an unnecessary restriction in the
context of
> client-side viewer scripting.  If I want to use a
> locally-installed package X from within my
client-side script,
> I should be able to.  What runs client-side should
always be
  

Re: [opensource-dev] Client-side scripting in Snowglobe

[Ron Festa]

To be honest the arguments I've been seeing about not using MONO seem to be
forgetting something. There are multiple languages that can be
compiled/interpreted in MONO with the appropriate addon, not just C#. Just
to name a few we have Python, Boo (which resembles Python and seems to come
with MONO now), Lua, Java, JavaScript, VisualBasic.NET, Pascal, PHP, and
with the work LL has done to the server we now have LSL. With MONO you have
options both in the language choice and what OS it can run on. The generated
code (whether compiled or interpreted) should be compatible with LL's server
sided script engine and should be compatible with OpenSIM.

Ron Festa
Virtual Worlds Admin
Division of Continuing Studies at Rutgers University
PGP key: http://bit.ly/b1ZyhY
Phone: 732-474-8583
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Lawson English]

Ron Festa wrote:
> To be honest the arguments I've been seeing about not using MONO seem 
> to be forgetting something. There are multiple languages that can be 
> compiled/interpreted in MONO with the appropriate addon, not just C#. 
> Just to name a few we have Python, Boo (which resembles Python and 
> seems to come with MONO now), Lua, Java, JavaScript, VisualBasic.NET, 
> Pascal, PHP, and with the work LL has done to the server we now have 
> LSL. With MONO you have options both in the language choice and what 
> OS it can run on. The generated code (whether compiled or interpreted) 
> should be compatible with LL's server sided script engine and should 
> be compatible with OpenSIM.
>
There's more to a language then just the syntax. CLR-based Smalltalk is 
NOT real smalltalk, for example.

There's no way except perhaps via F# to get something approaching 
smalltalk programming out of a CLR-based system.


Lawson


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Robin Cornelius]

On Fri, Feb 19, 2010 at 6:40 PM, Lawson English  wrote:
>>
> There's more to a language then just the syntax. CLR-based Smalltalk is
> NOT real smalltalk, for example.
>
> There's no way except perhaps via F# to get something approaching
> smalltalk programming out of a CLR-based system.
>

Well Morgaine's socket based idea could over come this very easily. If
the API was exposed via a socket, LL could provide a plugin loader
much as they do for the MediaAPI now, if they want, this pluginloader
could be CLR based and the default LL implementation of plugins could
be mono assemblies. So the plugin loader could be directly used by any
language that can produce CLR binaries.

If someone else comes along who does not use CLR, they could just
directly use the socket API with what ever lanuaguage they wanted
either directly, or via another plugin loader, but importantly, in
their lanugage of choice.

Sandboxing could easily be provided by the default LL pluginloader so
that out of the box implementation provides a save environment for any
downloaded scripts. But someone else who wants to call native
functions can from, again, any thing they like if it supports sockets.

I think something along these lines could provide something close to
maximum flexibilty.

Regards

Robin
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Lawson English]

Robin Cornelius wrote:
> On Fri, Feb 19, 2010 at 6:40 PM, Lawson English  wrote:
>   
>> There's more to a language then just the syntax. CLR-based Smalltalk is
>> NOT real smalltalk, for example.
>>
>> There's no way except perhaps via F# to get something approaching
>> smalltalk programming out of a CLR-based system.
>>
>> 
>
> Well Morgaine's socket based idea could over come this very easily. If
> the API was exposed via a socket, LL could provide a plugin loader
> much as they do for the MediaAPI now, if they want, this pluginloader
> could be CLR based and the default LL implementation of plugins could
> be mono assemblies. So the plugin loader could be directly used by any
> language that can produce CLR binaries.
>
> If someone else comes along who does not use CLR, they could just
> directly use the socket API with what ever lanuaguage they wanted
> either directly, or via another plugin loader, but importantly, in
> their lanugage of choice.
>
> Sandboxing could easily be provided by the default LL pluginloader so
> that out of the box implementation provides a save environment for any
> downloaded scripts. But someone else who wants to call native
> functions can from, again, any thing they like if it supports sockets.
>
> I think something along these lines could provide something close to
> maximum flexibilty.
>
> Regards
>
> Robin
> ___
>   

Sure. ANd in that case, I have no real objections. There's durned little 
difference between having a command parser written in C#, C++, or 
whatever and if one can use CLR scripts directly but still be able to 
evoke the internals of the system via a socket interface, that's fine.


Personally, if I ever wrote a Mac-only client, I'd use fscript as the 
internal scripting language because that is far, FAR slicker than 
anything CLR-based, but I'm a Mac fanboi.



Lawson


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Maggie Leber (sl: Maggie Darwin)]

The socket-based approach has the advantages of being
OS-platform-neutral, which CLR is not. A JVM-based scripting system
leveraging JSR-223 tech would be more platform-neutral, but is
certainly not what anybody could call "lightweight".

But either of those approaches (as well as others) could be
implemented up against Morgaine's suggestion, and scriptwriters could
choose what dependencies they cared to embrace.  I seem to recall not
long ago Philip had a project to implement camera-based facial
expression recognition whose design included a socket based viewer
interface.

(Of course, any client-side scripting will face an outcry from certain
well-known users who rail against making inherent capabilities of the
viewer/server system easier to access or automate as an "invasion of
privacy".)

I think asking the question "what would you *do* with scripting in the
client?" is premature until you identify what client functionality you
can or should expose to scripting. This is an issue I'm currently
wrestling with in working with Project Wonderland (
http://www.projectwonderland.com ), where the scripting architectures
(doesn't have to be restricted to only one implementation) are still
essentially greenfields and the underlying architecture is capable of
operating both on client and server-side objects.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Edward Artaud]

Smartest point made on the topic, and it really makes sense to stop
conflating the two, there are distinct untrusted script and trusted
plug-in problems.  For client-side scripts to be something worth
prioritizing implementing in mainstream viewers, their usage must be
based on the assumption that some large percentage (80+% maybe) of
attachment scripts, for example, would be running client-side, and
possibly even allowing in-world objects to specify that specific
scripts as meant to run viewer-side as well.  The analogy would be
that of web browsers, most of which have javascript enabled by default
and any single browser user is downloading and running *thousands* of
scripts over the course of a day with no awareness or explicit
permission given.  Getting a similar system to work in the viewer is a
big problem in and of itself to solve, and the one that would have the
most direct impact in the in-world experience of the most users in the
shortest period of time.  Plug-ins would be great, but then we get
into the questions of the whole process of how installation works, is
there an auto-installer ala IE or some form of manual mechanism that
will be prone to user error.  If there isn't a way that a very large
number of users would have easy access to trusted plug-ins, it's hard
to imagine it would be a highly prioritized feature.

On Thu, Feb 18, 2010 at 11:16 PM, Ricky  wrote:
> I suspect that there are two things being discussed here without
> distinction: Client scripting, and client extensions.  Confusing the two is
> easy.
> Client-side scripting SHOULD be sandboxed, and in a controlled set of
> languages.  For a close example think of javascript in web browsers.
> Client extensions, or alternatively named as "plugins", would be modules
> that can be plugged in and out of the client and run /as if/ they were a
> part of the client.  Think of browser add-ons/plugins/extensions.
> Client side scripts could (read might be, could possibly, needs further
> thought, etc.) be given permission to be loaded in by worn items
> automatically.  Other objects would likely need to request permission via a
> security warning.
> Client extensions would have to be downloaded and installed externally; not
> delivered in-world.  These would truly be programs on your computer, and
> should be treated as such.
> Just my thoughts hoping for a clearer discussion.
> Ricky
> Cron Stardust
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Maggie Leber (sl: Maggie Darwin)]

On Fri, Feb 19, 2010 at 2:49 PM, Edward Artaud  wrote:
>  For client-side scripts to be something worth
> prioritizing implementing in mainstream viewers, their usage must be
> based on the assumption that some large percentage (80+% maybe) of
> attachment scripts, for example, would be running client-side...

Uh...I didn't really see viewer-side scripting as something that would
make any significant dent in what's done today with scripted objects
serverside except in the case of some HUD objects.

I was thinking of this as new function, and only incidentally
providing some marginal performance relief for LLs servers in limited
cases...such as how Emerald's avatar radar reduces or eliminates
avatar radar HUDs.

Love to hear other views on this...
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Morgaine]

RLVa is a very notable user-defined API that has far transcended its
original purpose, and is now in extensive use wherever enhancements for
accessibility are required.  It really highlights how user-defined
functionality should have been in the viewer from the beginning.

Client-side scripting will undoubtedly take accessibility to the next level,
and I would fully expect RLV itself to become a common binding for many
client-side scripting languages.

Accessibility provides many good examples to illustrate how client-side
scripting would work over a socket-based API in the viewer.  Let's look at a
simple example that is of huge interest and benefit not only to the visually
impaired but to anyone who doesn't particularly enjoy reading scrolling
text:

-
SIMPLE TALKER SCRIPT

1) The user either executes the talker script manually (just like any
conventional program), or else the script launches automatically on viewer
startup, or else the script is launched from the viewer's script manager if
there is one.  If there are special accessibility issues to consider, this
step can be complicated, and tailored to the individual needs of the user.

2) The script immediately connects to a predefined port on the same machine
as the viewer, on which the viewer is listening for incoming script
connections.   The viewer's connection listener accepts the connection and
sets up the appropriate TCP channel and messaging command interface for
communicating with the script.

3) The script sends the viewer a message to register a callback for the
NewCommunicateTabOpened event, in order to be notified of new channels of
communication appearing in the viewer.

4) The viewer registers the callback for this script.  (Note that any number
of attached scripts could register interest in the same callback.)

5) Someone starts a personal IM to this user or sends an IM to one of the
user's groups, and a new Communications tab pops up in the viewer.  Since
the script has registered for the corresponding event, a message of the
appropriate type and naming the channel that has just appeared is sent by
the viewer to the script through the socket.

6) The script responds to the incoming event, and sends back a message to
register a callback for the ChatMessageReceived event, parametrized with N,
the number of old chat messages desired (1, if only the message that opened
the chat tab is wanted).

7) The viewer registers the callback and sends the requested N chat lines,
one per message of the appropriate type, parametrized with the channel
identifier and carrying the chat line as payload.  The types could be
different for personal and group IM, vicinity chat, system messages, etc.

8) The script receives each incoming chat event message and sends it to the
local text-to-speech program on the user's machine, which could be a
commercial package or an open source one such as Festival.  Note that the
script could apply transformations to each line to increase listenability,
including assigning gender or tiny voices as desired, or filtering out
undesired types of message such as graphic spam.

9) When no more chat talking is desired, the script can simply be killed.
The viewer will note the TCP socket closing and will remove all registered
callbacks for this script and tidy up appropriately.

END
-


It is very important to note that client-side scripts written for
accessibility purposes are very often interfaces to local resources or
applications, and cannot be sandboxed, since those resources or applications
would not be accessible from within a strong-walled sandbox.

This is why a sandboxed CLR environment is not enough for a generic
client-side scripting system --- it doesn't meet a very large set of crucial
use cases.  Both sandboxed and not sandboxed script environments are
required, to cater for untrusted and trusted scripts respectively.


Morgaine.






===

On Fri, Feb 19, 2010 at 3:47 PM, k\o\w  wrote:

>  RLVa, supports something like this, and can be found in most 3rd party
> viewers:
> http://rlva.catznip.com/blog/
> http://wiki.secondlife.com/wiki/RestrainedLifeAPI
>
>
> On 2/19/2010 10:38 AM, Morgaine wrote:
>
> Not forgetting Erlang, Ruby, LISP, Javascript, and Bourne shell of course.
> :-)
>
> But here's the fun one, for some value of "fun" ...  Someone would
> undoubtedly write an LSL binding to the socket-based API too.  And however
> much we screw up our noses at LSL, I have no doubt that a large number of SL
> users who know no other language would be very happy to see it. :-)
>
> Providing a socket-based interface to the viewer would be a hugely
> all-embracing approach to client-side scripting, supporting everyone's
> needs.  I think it deserves consideration.
>
>
> Morgaine.
>
>
>
>
> ===
>
> On Fri, Feb 19, 2010 at 3:23 PM, Morgaine 
> wrote:
>
>> Indeed Rob!
>>
>> Lua is a brilliant language for adding scripting to 

Re: [opensource-dev] Client-side scripting in Snowglobe

[Domino Marama]

On Fri, 2010-02-19 at 14:54 -0500, Maggie Leber (sl: Maggie Darwin)
wrote:
> I was thinking of this as new function, and only incidentally
> providing some marginal performance relief for LLs servers in limited
> cases...such as how Emerald's avatar radar reduces or eliminates
> avatar radar HUDs.
> 
> Love to hear other views on this...

I'd hope things like attachment sizing scripts would move to client side
scripts.

There's also things like advanced vehicle scripts, I wrote an engine
script that did an approximate handling of torque and grip. It was
fairly math intensive and I never implemented it fully as I judged the
sim load to be too great. If I can move that client side and just send
it's output to the server side physics script driving the vehicle, then
not only does it become a feasible approach, it'd possibly be lighter on
the sim than some current vehicle scripts.

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Community created interfaces already in use (was: Client-side scripting in Snowglobe)

[Boroondas Gupte]

I guess https://jira.secondlife.com/browse/SNOW-375 is using a similar
protocol.

cheers
Boroondas
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Maggie Leber (sl: Maggie Darwin)]

On Fri, Feb 19, 2010 at 3:08 PM, Domino Marama
 wrote:

> I'd hope things like attachment sizing scripts would move to client side
> scripts.

I guess that would be nice, but the data that would have to flow to
the attached hair prims would be substantialand the prims would
still have to be scripted. I wouldn't expect to see much savings from
that.

> There's also things like advanced vehicle scripts, I wrote an engine
> script that did an approximate handling of torque and grip. It was
> fairly math intensive and I never implemented it fully as I judged the
> sim load to be too great. If I can move that client side and just send
> it's output to the server side physics script driving the vehicle, then
> not only does it become a feasible approach, it'd possibly be lighter on
> the sim than some current vehicle scripts.

Might just want to use a SpaceNavigator for that.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Domino Marama]

On Fri, 2010-02-19 at 15:57 -0500, Maggie Leber (sl: Maggie Darwin)
wrote:
> On Fri, Feb 19, 2010 at 3:08 PM, Domino Marama
>  wrote:
> 
> > I'd hope things like attachment sizing scripts would move to client side
> > scripts.
> 
> I guess that would be nice, but the data that would have to flow to
> the attached hair prims would be substantialand the prims would
> still have to be scripted. I wouldn't expect to see much savings from
> that.

Depends on implementation. I'm assuming client side scripts won't need
transferring sim to sim on teleports, so scripts such as these that
don't need to be active on the sim seem like good candidates to me.

If anything I'd have thought the data flow with the vehicle scripts
would be more of an issue as that'd be constant messaging between the
client and server parts. It would need careful testing to make sure that
moving the maths client side was more efficient. Even without my crazy
ideas on doing torque based acceleration curves, it's likely that people
will overdo messaging (if it's a feature) with stuff like client hud
speedos for vehicles..


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Lawson English]

Maggie Leber (sl: Maggie Darwin) wrote:
> On Fri, Feb 19, 2010 at 2:49 PM, Edward Artaud  
> wrote:
>   
>>  For client-side scripts to be something worth
>> prioritizing implementing in mainstream viewers, their usage must be
>> based on the assumption that some large percentage (80+% maybe) of
>> attachment scripts, for example, would be running client-side...
>> 
>
> Uh...I didn't really see viewer-side scripting as something that would
> make any significant dent in what's done today with scripted objects
> serverside except in the case of some HUD objects.
>
> I was thinking of this as new function, and only incidentally
> providing some marginal performance relief for LLs servers in limited
> cases...such as how Emerald's avatar radar reduces or eliminates
> avatar radar HUDs.
>
> Love to hear other views on this...
>   

Depends on what is being done with it of course. a squeak interface 
(say) tied to the socket/shared memory connection could prototype just 
about any kind of extension/facility (as long as it used already 
existing events).

Suppose, for example, there was a way to use the media plugin's shared 
memory as  a sculpty map rather than simply as a texture to be painted 
on a prim.  One could manipulate the vertices of the sculpy via a plugin 
and have the changes show up in the client without putting extra strain 
on the sim. The state might be shared via p2p connections between 
clients' plugins,  or collaborative clients could share state 2 ways via 
a server (or p2p), while an audience could subscribe to a one-way 
connection of some kind, or the animation could be cached in a 
distributed file, or it might not be shared at all if someone were 
working on a test of a new animation and wanted to see what it would 
look like in-world before distribution.

One could have high-end content creation tools hooked into the client 
this way and manipulate anything from a prim or texture all the way to 
the full scenegraph. physics could be modded the same way. Likewise with 
custom scriptable objects.

This is basically a hybridization of the croquet/cobalt strategy for 
virtual worlds and the VWRAP strategy so anything you could do with 
either should be possible this way.

Lawson













___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Morgaine]

The client-side scripts that we are talking about in this thread are not
related to in-world LSL scripts in any way.  They always execute
client-side, isolated in their respective processes, and they only talk
directly to the client and sometimes also to local PC resources, such as the
text-to-speech example I described earlier.

Of course, if one of the viewer's script API functions provides
communication with the world, then indirectly the client-side script would
be able to interact with the world too, but that is indirect, by invoking a
viewer API function through a message.

It is entirely up to the viewer to define which messages are accepted from a
script and which API functions are invoked by that message.  Because scripts
can interact with the viewer only through the messaging interface, they
cannot do anything to the viewer or to the world that the viewer does not
permit.

Nothing would happen to a client-side script directly when you change
regions.  However,  the script could receive LeavingRegion and
EnteringRegion events from the viewer if it registered its interest in
callbacks for them.

Also, a script could register interest in CurrentPosition events, which the
viewer would send to the script periodically with a requested time interval,
or maybe with a requested spatial resolution granularity.

TRAVEL LOGGER

Add the region callbacks and position callbacks together and you have the
basis for a very simple *travel logger* script, logging your travels to your
local machine.  This could even play back its voyage and send you around the
world revisiting old places again.  That's another nice use case for
client-side scripting, and very simple to do.


Morgaine.



==

On Fri, Feb 19, 2010 at 9:35 PM, Domino Marama wrote:

> On Fri, 2010-02-19 at 15:57 -0500, Maggie Leber (sl: Maggie Darwin)
> wrote:
> > On Fri, Feb 19, 2010 at 3:08 PM, Domino Marama
> >  wrote:
> >
> > > I'd hope things like attachment sizing scripts would move to client
> side
> > > scripts.
> >
> > I guess that would be nice, but the data that would have to flow to
> > the attached hair prims would be substantialand the prims would
> > still have to be scripted. I wouldn't expect to see much savings from
> > that.
>
> Depends on implementation. I'm assuming client side scripts won't need
> transferring sim to sim on teleports, so scripts such as these that
> don't need to be active on the sim seem like good candidates to me.
>
> If anything I'd have thought the data flow with the vehicle scripts
> would be more of an issue as that'd be constant messaging between the
> client and server parts. It would need careful testing to make sure that
> moving the maths client side was more efficient. Even without my crazy
> ideas on doing torque based acceleration curves, it's likely that people
> will overdo messaging (if it's a feature) with stuff like client hud
> speedos for vehicles..
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Edward Artaud]

I'm certainly not against a general API for trusted plug-ins
(certainly all my emails to this list have been plug-in related), and
it would be awesome for tools to be built without everyone having to
create a viewer fork.  My assumption, however, is that client-side
script capability is meant to go hand in hand with the server-side
script memory limits, where if the script developer marks the script
as "run on client", they're able to run without the same memory limits
as running on the server.  If the client-side scripting project isn't
part of the same initiative as the server-side script memory
restrictions, it certainly should be, since one is the elegant
solution to the other.

On Fri, Feb 19, 2010 at 2:29 PM, Lawson English  wrote:
> Maggie Leber (sl: Maggie Darwin) wrote:
>>
>> On Fri, Feb 19, 2010 at 2:49 PM, Edward Artaud 
>> wrote:
>>
>>>
>>>  For client-side scripts to be something worth
>>> prioritizing implementing in mainstream viewers, their usage must be
>>> based on the assumption that some large percentage (80+% maybe) of
>>> attachment scripts, for example, would be running client-side...
>>>
>>
>> Uh...I didn't really see viewer-side scripting as something that would
>> make any significant dent in what's done today with scripted objects
>> serverside except in the case of some HUD objects.
>>
>> I was thinking of this as new function, and only incidentally
>> providing some marginal performance relief for LLs servers in limited
>> cases...such as how Emerald's avatar radar reduces or eliminates
>> avatar radar HUDs.
>>
>> Love to hear other views on this...
>>
>
> Depends on what is being done with it of course. a squeak interface (say)
> tied to the socket/shared memory connection could prototype just about any
> kind of extension/facility (as long as it used already existing events).
>
> Suppose, for example, there was a way to use the media plugin's shared
> memory as  a sculpty map rather than simply as a texture to be painted on a
> prim.  One could manipulate the vertices of the sculpy via a plugin and have
> the changes show up in the client without putting extra strain on the sim.
> The state might be shared via p2p connections between clients' plugins,  or
> collaborative clients could share state 2 ways via a server (or p2p), while
> an audience could subscribe to a one-way connection of some kind, or the
> animation could be cached in a distributed file, or it might not be shared
> at all if someone were working on a test of a new animation and wanted to
> see what it would look like in-world before distribution.
>
> One could have high-end content creation tools hooked into the client this
> way and manipulate anything from a prim or texture all the way to the full
> scenegraph. physics could be modded the same way. Likewise with custom
> scriptable objects.
>
> This is basically a hybridization of the croquet/cobalt strategy for virtual
> worlds and the VWRAP strategy so anything you could do with either should be
> possible this way.
>
> Lawson
>
>
>
>
>
>
>
>
>
>
>
>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Mike Monkowski]

Client-side scripts can only operate on data that is client-side.  It 
means that they do not operated directly on in-world objects.  They only 
access the client's representation of those objects.  Any actions 
performed by a client-side script would only be visible to that 
particular client.  So attachment scripts and vehicle scripts are not 
candidates for client-side scripting.

Before worrying about what language the scripts should be written in, 
someone has to figure out functions that can operate on the client data 
model.  So anything related to chat is fair game, as is anything related 
to polygons and meshes, although any modifications to these would be 
visible only locally (like beacons).  Anything related to the UI could 
be scripted client-side.  Accessibility extensions could be client-side.

Emerald uses a lot of information in the local avatars data model for 
its radar.  Those kinds of things would be available for defining getter 
functions.

But expect that most functions that operate server-side (most LSL 
functions) will not be able to operate client-side.  You can't just 
offload those functions to the client.  It would be like talking to your 
television and expecting the characters on the screen to hear you.  If 
the capability doesn't exist in the client-to-server messages now, a 
client-side script could not communicate it to the servers, where all 
assets reside.

Mike

Domino Marama wrote:
> On Fri, 2010-02-19 at 15:57 -0500, Maggie Leber (sl: Maggie Darwin)
> wrote:
> 
>>On Fri, Feb 19, 2010 at 3:08 PM, Domino Marama
>> wrote:
>>
>>
>>>I'd hope things like attachment sizing scripts would move to client side
>>>scripts.
>>
>>I guess that would be nice, but the data that would have to flow to
>>the attached hair prims would be substantialand the prims would
>>still have to be scripted. I wouldn't expect to see much savings from
>>that.
> 
> 
> Depends on implementation. I'm assuming client side scripts won't need
> transferring sim to sim on teleports, so scripts such as these that
> don't need to be active on the sim seem like good candidates to me.
> 
> If anything I'd have thought the data flow with the vehicle scripts
> would be more of an issue as that'd be constant messaging between the
> client and server parts. It would need careful testing to make sure that
> moving the maths client side was more efficient. Even without my crazy
> ideas on doing torque based acceleration curves, it's likely that people
> will overdo messaging (if it's a feature) with stuff like client hud
> speedos for vehicles..
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Morgaine]

No Edward, client-side scripting is not related to in-world scripting at
all.  It's scripting OF THE CLIENT, and it has the sole purpose of extending
the functionality of the client, on a personal basis.

While it's nice to hypothesize about in-world scripts being off-loadable to
the client, that is merely a conceptual idea without any concrete suggestion
for how it could be implemented.  It's not what we've been talking about
here.


Morgaine.



===

On Fri, Feb 19, 2010 at 10:50 PM, Edward Artaud wrote:

> I'm certainly not against a general API for trusted plug-ins
> (certainly all my emails to this list have been plug-in related), and
> it would be awesome for tools to be built without everyone having to
> create a viewer fork.  My assumption, however, is that client-side
> script capability is meant to go hand in hand with the server-side
> script memory limits, where if the script developer marks the script
> as "run on client", they're able to run without the same memory limits
> as running on the server.  If the client-side scripting project isn't
> part of the same initiative as the server-side script memory
> restrictions, it certainly should be, since one is the elegant
> solution to the other.
>
> On Fri, Feb 19, 2010 at 2:29 PM, Lawson English  wrote:
> > Maggie Leber (sl: Maggie Darwin) wrote:
> >>
> >> On Fri, Feb 19, 2010 at 2:49 PM, Edward Artaud  >
> >> wrote:
> >>
> >>>
> >>>  For client-side scripts to be something worth
> >>> prioritizing implementing in mainstream viewers, their usage must be
> >>> based on the assumption that some large percentage (80+% maybe) of
> >>> attachment scripts, for example, would be running client-side...
> >>>
> >>
> >> Uh...I didn't really see viewer-side scripting as something that would
> >> make any significant dent in what's done today with scripted objects
> >> serverside except in the case of some HUD objects.
> >>
> >> I was thinking of this as new function, and only incidentally
> >> providing some marginal performance relief for LLs servers in limited
> >> cases...such as how Emerald's avatar radar reduces or eliminates
> >> avatar radar HUDs.
> >>
> >> Love to hear other views on this...
> >>
> >
> > Depends on what is being done with it of course. a squeak interface (say)
> > tied to the socket/shared memory connection could prototype just about
> any
> > kind of extension/facility (as long as it used already existing events).
> >
> > Suppose, for example, there was a way to use the media plugin's shared
> > memory as  a sculpty map rather than simply as a texture to be painted on
> a
> > prim.  One could manipulate the vertices of the sculpy via a plugin and
> have
> > the changes show up in the client without putting extra strain on the
> sim.
> > The state might be shared via p2p connections between clients' plugins,
>  or
> > collaborative clients could share state 2 ways via a server (or p2p),
> while
> > an audience could subscribe to a one-way connection of some kind, or the
> > animation could be cached in a distributed file, or it might not be
> shared
> > at all if someone were working on a test of a new animation and wanted to
> > see what it would look like in-world before distribution.
> >
> > One could have high-end content creation tools hooked into the client
> this
> > way and manipulate anything from a prim or texture all the way to the
> full
> > scenegraph. physics could be modded the same way. Likewise with custom
> > scriptable objects.
> >
> > This is basically a hybridization of the croquet/cobalt strategy for
> virtual
> > worlds and the VWRAP strategy so anything you could do with either should
> be
> > possible this way.
> >
> > Lawson
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Latif Khalifa]

People seem to be confusing two different things: client side
scripting, and client extensions or plugins.

1. Client side scripting

Think web browsers. They all support execution of client side scripts
in one language in sandboxed environment. So the way original post
describes proposed design for client side scripting fits neatly in
this scenario.

Having a unified platform that scripts can depend on existing in the
client (say viewer 2.3 and up support it) would allow all sort of new
and innovative content to be created.

2. Plugins

Think Firefox extensions/plugins. Like Flash, Java applets, etc. This
is entirely different concept. In-world content cannot depend on these
being present, and have to allow for situation where  some users have
some plugins installed, while other do not.

Both of these concepts would be a welcome addition to the viewer. I
would imagine that the needed internal changes to the viewer could be,
at least partially, used for implementation of both. If the first step
is to implement client side scripting as described above, we should be
talking about it, and separate plugin discussion into a different
thread.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Tateru Nino]

When I think of client-side scripting for the viewer, I'm definitely
thinking of the latter, not the former. Inworld objects sending limited
scripted tasks to the viewer? Doesn't even seem all that useful or
desirable, though surely there must be *some* use-cases.

On the other hand, being able to plug scripts of my own (or others')
devising in to the viewer to improve accessibility and customize
usability? Huge win. I've got endless numbers of invoicing and
communication tasks that would benefit from being able to build my own
data-pipelines or just save myself clicks and keystrokes every time around.


On 20/02/2010 10:14 AM, Latif Khalifa wrote:
> People seem to be confusing two different things: client side
> scripting, and client extensions or plugins.
>
> 1. Client side scripting
>
> Think web browsers. They all support execution of client side scripts
> in one language in sandboxed environment. So the way original post
> describes proposed design for client side scripting fits neatly in
> this scenario.
>
> Having a unified platform that scripts can depend on existing in the
> client (say viewer 2.3 and up support it) would allow all sort of new
> and innovative content to be created.
>
> 2. Plugins
>
> Think Firefox extensions/plugins. Like Flash, Java applets, etc. This
> is entirely different concept. In-world content cannot depend on these
> being present, and have to allow for situation where  some users have
> some plugins installed, while other do not.
>
> Both of these concepts would be a welcome addition to the viewer. I
> would imagine that the needed internal changes to the viewer could be,
> at least partially, used for implementation of both. If the first step
> is to implement client side scripting as described above, we should be
> talking about it, and separate plugin discussion into a different
> thread.
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>
>   

-- 
Tateru Nino
Contributing Editor http://massively.com/

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Morgaine]

That's not a good choice of terms, Latif, as it doesn't distinguish between
the two cases:  one in which the script is untrusted and hence sandboxed,
and the other in which the script is trusted and can freely hook into
platform facilities.


On Fri, Feb 19, 2010 at 11:14 PM, Latif Khalifa wrote:

> People seem to be confusing two different things: client side
> scripting, and client extensions or plugins.
>
> 1. Client side scripting
>
>
Both our cases use scripts, and in both cases the scripts run client-side.
Therefore both cases are examples of *client-side scripting*.  This is not a
good phrase for distinguishing between the two cases.



> Think web browsers. They all support execution of client side scripts
> in one language in sandboxed environment. So the way original post
> describes proposed design for client side scripting fits neatly in
> this scenario.
>
> Having a unified platform that scripts can depend on existing in the
> client (say viewer 2.3 and up support it) would allow all sort of new
> and innovative content to be created.
>
> 2. Plugins
>
>
"Plugin" denotes a mechanism for adding some programmed functionality, but
that applies to both our cases.  Plugins can be autoloaded on demand, and if
they're untrusted and run in a sandbox then this doesn't even need any user
confirmation.  Again, this mechanism word doesn't distinguish between the
untrusted+sandboxed case and the trusted one.  Both could be implemented as
plugins, and the word really means too many things to help us.  For example,
plugins that load into the host application address space are common, but
plugins that run in a separate process are also available, and becoming more
common because of multicore.  This word doesn't help us disambiguate our two
cases.



> Think Firefox extensions/plugins. Like Flash, Java applets, etc. This
> is entirely different concept. In-world content cannot depend on these
> being present, and have to allow for situation where  some users have
> some plugins installed, while other do not.
>
> Both of these concepts would be a welcome addition to the viewer. I
> would imagine that the needed internal changes to the viewer could be,
> at least partially, used for implementation of both. If the first step
> is to implement client side scripting as described above, we should be
> talking about it, and separate plugin discussion into a different
> thread.
>



While I think we both agree on the nature of the two cases, it seems hard to
find good labels to describe them concisely yet correctly. :-)


Morgaine.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Rob Nelson]

My main problem with Socket-based thing is that it opens up all kinds of
problems, ranging from outside apps screwing with the socket and doing
stuff that the user has not authorized, to simple security concerns (I'm
sure as hell going to trust a readable
Lua/LSL/shell/anything-other-than-LISP script more than a binary
executable or shared library), to platform issues (opening local
listeners may piss off certain software firewall implementations), not
to mention the sheer amount of data that must be converted to and from
UDP/TCP and transferred over a connection, which could cause latency.  

Having an embedded scripting engine is simply easier for script-writers,
too.  All a user needs to know is what functions to use and where to put
the sourcecode, whereas a socket-based solution means that a networking
API must be present, and the user must maintain a constant connection to
SL's process, requiring them to either have a provided API that supports
their language (consider the sheer amount of maintenance this would
require), or have TCP/IP experience and functions.

I'm all for having a way to dynamically load a scripting engine
DLL/SO/DYLIB, but I'm not very comfortable forcing users to use sockets
in order to interface with their client.  There are other ways that
aren't as risky, complex, and laggy, and trust me, I'm having enough
trouble integrating Lua with SL.  The huge level of maintenance and
dependency-juggling that just two language APIs would present could
overwhelm even the Emerald dev team.

On Fri, 2010-02-19 at 10:47 -0500, k\o\w wrote:
> RLVa, supports something like this, and can be found in most 3rd party
> viewers:
> http://rlva.catznip.com/blog/
> http://wiki.secondlife.com/wiki/RestrainedLifeAPI
> 
> On 2/19/2010 10:38 AM, Morgaine wrote: 
> > Not forgetting Erlang, Ruby, LISP, Javascript, and Bourne shell of
> > course. :-)
> > 
> > But here's the fun one, for some value of "fun" ...  Someone would
> > undoubtedly write an LSL binding to the socket-based API too.  And
> > however much we screw up our noses at LSL, I have no doubt that a
> > large number of SL users who know no other language would be very
> > happy to see it. :-)
> > 
> > Providing a socket-based interface to the viewer would be a hugely
> > all-embracing approach to client-side scripting, supporting
> > everyone's needs.  I think it deserves consideration.
> > 
> > 
> > Morgaine.
> > 
> > 
> > 
> > 
> > ===
> > 
> > On Fri, Feb 19, 2010 at 3:23 PM, Morgaine
> >  wrote:
> > Indeed Rob!
> > 
> > Lua is a brilliant language for adding scripting to existing
> > applications --- it's designed expressly for embedding and
> > extending, it has a clean syntax, it is linguistically very
> > powerful, it is very tiny (the whole thing can add under
> > 100KB to your application), it can run sandboxed or not as
> > desired, and it is one of the fastest pure scripting
> > languages currently available, a lot faster than say Python.
> > 
> > It is no surprise then that game developers worldwide
> > flocked to it in droves, and now it's one of the most common
> > scripting languages found embedded in games.  WoW fans use
> > it daily as an intrinsic part of their WoW client, and a
> > huge community has grown up around Lua-powered interfaces
> > for that game.
> > 
> > So yes, I'm with you on the importance of Lua for
> > client-side scripting of the viewer.
> > 
> > However, advocating Lua as the sole means of scripting
> > viewers would be just as bad a mistake as advocating C# or
> > CLR-targetted languages only.  It would support only one
> > part of the scripting community directly, while
> > discriminating against everyone else.  This is not
> > necessary.
> > 
> > Instead, defining a socket-based API interface would allow
> > effectively any language to be used for scripting the
> > viewer, since virtually all languages today have socket
> > capabilities.  That would certainly include Lua and C# and
> > Python and Perl and Java and Clojure and C/C++ and
> > ObjectiveC and Smalltalk, to name a few languages that this
> > community uses regularly.
> > 
> > The only thing that we would have to agree on would be the
> > set of messages that cross the socket interface, and the set
> > of functions and callbacks that the messages would engage in
> > the viewer.  That's the kind of productive technical
> > discussion we could be having with Lindens, if their design
> > process for client-side scripting were open.  It needs to
> > be.
> > 
> > 
> > Morgaine.
> > 
> > 
> > 
> > 
> > 
> > 

Re: [opensource-dev] Client-side scripting in Snowglobe

[k\o\w]

According to the latest Emerald change log they've removed LUA altogether.

Regardless of where the scripts are executed, I think it's safe to 
assume that LL will deliver a robust, well protected system that 
provides very limited (but very useful) access to the viewer and thus 
minimizes exploit vectors. Look at LSL, prims, avatars, sculpts, the 
coming mesh models, etc. Everything in SL is the textbook definition of 
proprietary, and for very good reason. Without these constraints we 
would have a lot of  broken and laggy content, and exploits much worse 
than what is being abused currently.

There is no reason to think that Linden would provide something that 
could pose a real security risk to your system. It is guaranteed that 
their implementation will be an invaluable addition to SL, will allow 
you to plaster penises all over the viewer, and will be abused for years 
to come by griffers.


On 2/19/2010 7:51 PM, Rob Nelson wrote:
> My main problem with Socket-based thing is that it opens up all kinds of
> problems, ranging from outside apps screwing with the socket and doing
> stuff that the user has not authorized, to simple security concerns (I'm
> sure as hell going to trust a readable
> Lua/LSL/shell/anything-other-than-LISP script more than a binary
> executable or shared library), to platform issues (opening local
> listeners may piss off certain software firewall implementations), not
> to mention the sheer amount of data that must be converted to and from
> UDP/TCP and transferred over a connection, which could cause latency.
>
> Having an embedded scripting engine is simply easier for script-writers,
> too.  All a user needs to know is what functions to use and where to put
> the sourcecode, whereas a socket-based solution means that a networking
> API must be present, and the user must maintain a constant connection to
> SL's process, requiring them to either have a provided API that supports
> their language (consider the sheer amount of maintenance this would
> require), or have TCP/IP experience and functions.
>
> I'm all for having a way to dynamically load a scripting engine
> DLL/SO/DYLIB, but I'm not very comfortable forcing users to use sockets
> in order to interface with their client.  There are other ways that
> aren't as risky, complex, and laggy, and trust me, I'm having enough
> trouble integrating Lua with SL.  The huge level of maintenance and
> dependency-juggling that just two language APIs would present could
> overwhelm even the Emerald dev team.
>
> On Fri, 2010-02-19 at 10:47 -0500, k\o\w wrote:
>
>> RLVa, supports something like this, and can be found in most 3rd party
>> viewers:
>> http://rlva.catznip.com/blog/
>> http://wiki.secondlife.com/wiki/RestrainedLifeAPI
>>
>> On 2/19/2010 10:38 AM, Morgaine wrote:
>>  
>>> Not forgetting Erlang, Ruby, LISP, Javascript, and Bourne shell of
>>> course. :-)
>>>
>>> But here's the fun one, for some value of "fun" ...  Someone would
>>> undoubtedly write an LSL binding to the socket-based API too.  And
>>> however much we screw up our noses at LSL, I have no doubt that a
>>> large number of SL users who know no other language would be very
>>> happy to see it. :-)
>>>
>>> Providing a socket-based interface to the viewer would be a hugely
>>> all-embracing approach to client-side scripting, supporting
>>> everyone's needs.  I think it deserves consideration.
>>>
>>>
>>> Morgaine.
>>>
>>>
>>>
>>>
>>> ===
>>>
>>> On Fri, Feb 19, 2010 at 3:23 PM, Morgaine
>>>   wrote:
>>>  Indeed Rob!
>>>
>>>  Lua is a brilliant language for adding scripting to existing
>>>  applications --- it's designed expressly for embedding and
>>>  extending, it has a clean syntax, it is linguistically very
>>>  powerful, it is very tiny (the whole thing can add under
>>>  100KB to your application), it can run sandboxed or not as
>>>  desired, and it is one of the fastest pure scripting
>>>  languages currently available, a lot faster than say Python.
>>>
>>>  It is no surprise then that game developers worldwide
>>>  flocked to it in droves, and now it's one of the most common
>>>  scripting languages found embedded in games.  WoW fans use
>>>  it daily as an intrinsic part of their WoW client, and a
>>>  huge community has grown up around Lua-powered interfaces
>>>  for that game.
>>>
>>>  So yes, I'm with you on the importance of Lua for
>>>  client-side scripting of the viewer.
>>>
>>>  However, advocating Lua as the sole means of scripting
>>>  viewers would be just as bad a mistake as advocating C# or
>>>  CLR-targetted languages only.  It would support only one
>>>  part of the scripting community directly, while
>>>  discriminating against everyone else.  This is not
>>>  necessary.
>>>
>>>  Instead, defining a socket-based API 

Re: [opensource-dev] Client-side scripting in Snowglobe

[Lawson English]

Mike Monkowski wrote:
> Client-side scripts can only operate on data that is client-side.  It 
> means that they do not operated directly on in-world objects.  They only 
> access the client's representation of those objects.  Any actions 
> performed by a client-side script would only be visible to that 
> particular client.  So attachment scripts and vehicle scripts are not 
> candidates for client-side scripting.
>   


Not using the current server-centric model of SL, true.

But a packet injector based on grid-proxy could easily inject an object 
the sim doesn't know about and control its behavior independently of 
what the sim says to do. In fact, that is how the puppeteering code 
worked to a certain extent, although I remain confused as to whether or 
not feedback for the UI manipulations was cllientside or sent back to 
the server first and then sent to the originating client as part of the 
general broadcast to everyone in the sim.

Either strategy would have advantages and disadvantages I suspect and 
either one might make more sense in certain contexts.


There's been some talk of client-side physics being extended. 
Obviously,  once you start doing that, the sim has less and less control 
over what goes on. The ultimate form would be p2p-ish physics where the 
sim doesn't participate at all in anything but sending geometry updates 
and all calculations are shared between clients, either in a cobalt 
fashion, or using a separate physics server (or hybrid).



> Before worrying about what language the scripts should be written in, 
> someone has to figure out functions that can operate on the client data 
> model.  So anything related to chat is fair game, as is anything related 
> to polygons and meshes, although any modifications to these would be 
> visible only locally (like beacons).  Anything related to the UI could 
> be scripted client-side.  Accessibility extensions could be client-side.
>
>   
if you think of the teatime object server used in cobalt as a 
distributed state server, you could see a scenario where all 
manipulation is done using smalltalk TObjects and distributed to a 
teatime server which then passes the updates back down to everyone 
(including the client originating the UI manipulations).

SL client => UI plugin=> teatime service  <=  UI plugin <=  SL client
  V
  V
SL client <= xx-plugin<= teatime service   => xx=plugin => SL client



> Emerald uses a lot of information in the local avatars data model for 
> its radar.  Those kinds of things would be available for defining getter 
> functions.
>
> But expect that most functions that operate server-side (most LSL 
> functions) will not be able to operate client-side.  You can't just 
> offload those functions to the client.  It would be like talking to your 
> television and expecting the characters on the screen to hear you.  If 
> the capability doesn't exist in the client-to-server messages now, a 
> client-side script could not communicate it to the servers, where all 
> assets reside.
>
>   

Except NEW behavior that is passed back and forth between clients 
independently of the sim, or passed back to the sim as an afterthought 
to an audience that isn't participating in the race/combat/whatever, so 
they don't need the custom physics/etc packets.



Lawson
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Lawson English]

Morgaine wrote:
> No Edward, client-side scripting is not related to in-world scripting 
> at all.  It's scripting OF THE CLIENT, and it has the sole purpose of 
> extending the functionality of the client, on a personal basis.
>
> While it's nice to hypothesize about in-world scripts being 
> off-loadable to the client, that is merely a conceptual idea without 
> any concrete suggestion for how it could be implemented.  It's not 
> what we've been talking about here.
>

Its not NOT what we're talking about, either.

;-)


Plugins/scripting could include client-side services to replace/augment 
services currently provided by the sim, either for display locally, or 
via caps shared between clients or through external servers or whatever 
to allow for shared experiences without overwhelming the sim with new 
stuff.

Lawson



___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Argent Stonecutter]

> and this is where languages like perl/python have a strength since the
> files are plain text
> so if you think that a script is doing something funky you can just
> look at the script and see. Mono/dotnet code is compiled and very
> easily could hide just about anything.

I think using anything but Lua or Javascript (each of which has  
sandboxed implementations and a community of people already familiar  
with client-side scripting like this) for any kind of server-pushed  
client side scripting needs an exceptional justification. The only  
case I can se for using Mono here is to allow people to write client- 
side scripts that can not be easily eyeballed by the users. There is  
of course a community in SL which would consider this an important  
goal, but given the state of the client and the security model (and  
I'd be happy to discuss that offlist) I don't think that's a  
reasonable design goal.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Argent Stonecutter]

On 2010-02-19, at 01:16, Ricky wrote:

> I suspect that there are two things being discussed here without  
> distinction: Client scripting, and client extensions.  Confusing the  
> two is easy.
>
> Client-side scripting SHOULD be sandboxed, and in a controlled set  
> of languages.  For a close example think of javascript in web  
> browsers.
>
> Client extensions, or alternatively named as "plugins", would be  
> modules that can be plugged in and out of the client and run /as if/  
> they were a part of the client.  Think of browser add-ons/plugins/ 
> extensions.
>
> Client side scripts could (read might be, could possibly, needs  
> further thought, etc.) be given permission to be loaded in by worn  
> items automatically.  Other objects would likely need to request  
> permission via a security warning.
>
> Client extensions would have to be downloaded and installed  
> externally; not delivered in-world.  These would truly be programs  
> on your computer, and should be treated as such.
>
> Just my thoughts hoping for a clearer discussion.

A very good summary. Thank you.

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Tateru Nino]

Okay, so which one of these is the Lab thinking about, then? That'll
settle a lot of debate right there.

On 20/02/2010 2:00 PM, Argent Stonecutter wrote:
> On 2010-02-19, at 01:16, Ricky wrote:
>
>   
>> I suspect that there are two things being discussed here without  
>> distinction: Client scripting, and client extensions.  Confusing the  
>> two is easy.
>>
>> Client-side scripting SHOULD be sandboxed, and in a controlled set  
>> of languages.  For a close example think of javascript in web  
>> browsers.
>>
>> Client extensions, or alternatively named as "plugins", would be  
>> modules that can be plugged in and out of the client and run /as if/  
>> they were a part of the client.  Think of browser add-ons/plugins/ 
>> extensions.
>>
>> Client side scripts could (read might be, could possibly, needs  
>> further thought, etc.) be given permission to be loaded in by worn  
>> items automatically.  Other objects would likely need to request  
>> permission via a security warning.
>>
>> Client extensions would have to be downloaded and installed  
>> externally; not delivered in-world.  These would truly be programs  
>> on your computer, and should be treated as such.
>>
>> Just my thoughts hoping for a clearer discussion.
>> 
> A very good summary. Thank you.
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>
>   

-- 
Tateru Nino
http://dwellonit.taterunino.net/

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Argent Stonecutter]

On 2010-02-19, at 12:53, Robin Cornelius wrote:
> Well Morgaine's socket based idea could over come this very easily. If
> the API was exposed via a socket, LL could provide a plugin loader
> much as they do for the MediaAPI now, if they want, this pluginloader
> could be CLR based and the default LL implementation of plugins could
> be mono assemblies. So the plugin loader could be directly used by any
> language that can produce CLR binaries.

I suggested a socket based extension mechanism some years ago and was  
knocked down because you couldn't do things that required high  
performance access to textures, shaders, and so on. If that overhead  
is acceptable, then the socket mechanism would be completely language- 
agnostic, and it might even act as a legal firewall between the GPLed  
client and extensions.

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Argent Stonecutter]

On 2010-02-19, at 18:51, Rob Nelson wrote:

> My main problem with Socket-based thing is that it opens up all  
> kinds of
> problems, ranging from outside apps screwing with the socket and doing
> stuff that the user has not authorized,

If the socket is bound to 127.0.0.1 then only applications on the  
local machine can connect to and register with it.

> to simple security concerns (I'm
> sure as hell going to trust a readable
> Lua/LSL/shell/anything-other-than-LISP script more than a binary
> executable or shared library),

This mechanism would allow your script to be written in Perl, Python,  
Seamonkey (standalone javascript), Lisp, VBscript, Applescript, Tcl,  
Lua, Icon, even shell. They would not need to be binaries.


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Morgaine]

I'll try to answer your question, Tateru.

Judging by the only two facts that have been been divulged to us (Mono, and
sandbox), it seems a reasonable *guess* (important word) that they're
intending to support distributed CLR binaries that run "safely" (important
quotes) in a sandbox, and hence cannot interface to any user facilities
outside of the sandbox.

As will be clear to even the most modest of "power users", this is wholly
inadequate on numerous fronts, which I enumerated in the thread starter
article.  It doesn't support the most important aspect of client-side
scripting by far, which is to empower the user in any way she sees fit
through full-power local scripting, often interfacing to local facilities
which cannot be done from a sandbox.  Supporting accessibility requires
this.

The choice of Mono/CLR is also inadequate, for reasons already given, but it
gets worse.  Mono in the client should have Lindens screaming away in
horror, given the support nightmare that this will create.  This will be a
major new language subsystem to fail, with bugs arising for every binding
that they will have to support.  It contrasts extremely badly with the
comparatively tiny task of supporting some API functions and callbacks plus
a very small socket interface.

It's just my guess though.  And that's the travesty of this.  Why the blazes
is a major design for an open source viewer, in a project expressly set up
to foster cooperation with the open source community, being done in secret?
Why do we have to guess?  Why is this not being designed with the community,
openly, in the same spirit as they expect the community to help them find
and fix bugs?

It's really not right.


Morgaine.




===

On Sat, Feb 20, 2010 at 3:06 AM, Tateru Nino  wrote:

> Okay, so which one of these is the Lab thinking about, then? That'll
> settle a lot of debate right there.
>
> On 20/02/2010 2:00 PM, Argent Stonecutter wrote:
> > On 2010-02-19, at 01:16, Ricky wrote:
> >
> >
> >> I suspect that there are two things being discussed here without
> >> distinction: Client scripting, and client extensions.  Confusing the
> >> two is easy.
> >>
> >> Client-side scripting SHOULD be sandboxed, and in a controlled set
> >> of languages.  For a close example think of javascript in web
> >> browsers.
> >>
> >> Client extensions, or alternatively named as "plugins", would be
> >> modules that can be plugged in and out of the client and run /as if/
> >> they were a part of the client.  Think of browser add-ons/plugins/
> >> extensions.
> >>
> >> Client side scripts could (read might be, could possibly, needs
> >> further thought, etc.) be given permission to be loaded in by worn
> >> items automatically.  Other objects would likely need to request
> >> permission via a security warning.
> >>
> >> Client extensions would have to be downloaded and installed
> >> externally; not delivered in-world.  These would truly be programs
> >> on your computer, and should be treated as such.
> >>
> >> Just my thoughts hoping for a clearer discussion.
> >>
> > A very good summary. Thank you.
> >
> > ___
> > Policies and (un)subscribe information available here:
> > http://wiki.secondlife.com/wiki/OpenSource-Dev
> > Please read the policies before posting to keep unmoderated posting
> privileges
> >
> >
>
> --
> Tateru Nino
> http://dwellonit.taterunino.net/
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Lawson English]

Argent Stonecutter wrote:
> On 2010-02-19, at 12:53, Robin Cornelius wrote:
>   
>> Well Morgaine's socket based idea could over come this very easily. If
>> the API was exposed via a socket, LL could provide a plugin loader
>> much as they do for the MediaAPI now, if they want, this pluginloader
>> could be CLR based and the default LL implementation of plugins could
>> be mono assemblies. So the plugin loader could be directly used by any
>> language that can produce CLR binaries.
>> 
>
> I suggested a socket based extension mechanism some years ago and was  
> knocked down because you couldn't do things that required high  
> performance access to textures, shaders, and so on. If that overhead  
> is acceptable, then the socket mechanism would be completely language- 
> agnostic, and it might even act as a legal firewall between the GPLed  
> client and extensions.
>
>   

"Socket" can be another term for "IPC" in this context. I can create a 
shared memory buffer using FFI calls in squeak, then draw to it using 
squeak calls to OPenGL. Same would apply using pure smalltalk drawing 
commands.  The next step is to grab the shared buffer that the SL media 
plugin API creates and draw to  that instead. At that point, anything 
drawn via squeak becomes a local  SL texture ala the media plugin.

Share those drawing commands between squeak instances over the internet 
and you have automatic updates to any participating client in a 
collaborative whiteboard scenario (any OOP object in squeak can be based 
off of TObject instead of Object, so the full P2P collaborative 
semantics of croquet can be used for anythign from a full blown virtual 
world, to a single realtime drawing on the side of a SL prim). For 
efficiency with people who don't need collaboration you can 
instead-of/in-addition-to stream the updated texture to a quicktime or 
other media server and use the current SL mechanisms to show a read-only 
version of your whiteboarded texture ala html/QT on a prim. Same would 
apply for any other kind of collaboration from building to scripting to 
sculpties to [fill in the blank with something no-one has thought of 
yet].  Variations of this strategy using other collaborative services 
and languages besides squeak smalltalk could be used instead of/in 
addition to.

I'm just prototyping things in squeak because of the realtime nature of 
smalltalk development plus the already existing  resources that exist in 
the TeaTime P2P client-server architecture as implemented in croquet.


So "socket" IS being embraced officially in the SnowGlobe client via the 
media plugin (there is provision in the plugin design for mouse/keyboard 
events to be sent to/from the plugin via genuine socket IPC rather than 
shared memory) and the model can be extended as above to handle 
literally ANYTHING if you want to, assuming the internal events/API are 
exposed to the outside world. Morgaine and I advocate that EVERYTHING be 
exposed in principle with sandboxing done via registration of external 
event handlers on a per-plugin basis. By default every event handler 
permission is turned off, and you must both manually install the plugin 
and enable it to  register event handlers using some currently undefined 
process (check boxes/white lists/etc) that the plugins can't bypass.


This gives scripting languages and plugins  the ability, in theory, to 
modify the behavior of the client in literally any conceivable way as 
long as the event handlers are explicitly enabled. "Events" might 
include raw packets ala what can be injected via gridproxy, or GUI 
events (button press/mouse movement) or human-like commands (teleport to 
new world/sim ) or physics calculations or new kinds of IM messaging or 
custom building controls, etc., etc.

Adding entirely new features might require a lower level access which 
may or may not be scriptable, but client-side "scripting" at the  level 
Morgaine and I are talking about can interact with literally any 
existing function and blur the distinction between "scripting" and many 
plugins. As to how these events are handled internally, and whether or 
not some language framework (mono/.net) is given a first amongst peers 
status, that's another question, but what *I* am hoping for is that the 
external socket/IPC/plugin interface be given a first class citizenship, 
even if there's an extra layer for non CLR languages and systems.


And smalltalk syntax may work with the CLR, but the smalltalk IDE is 
incompatible with CLR, so there must be a level of indirection for a 
smalltalk based plugin to work.

Lawson





Lawson











Lawson

















___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges