Re: [opensource-dev] State machine class
State machines are very useful, but the use case you gave is an example of a user application that should be coded in an attached script. The fact that the viewer does not yet have attached client-side scripting is not a reason for putting the user application directly into the viewer. It's a reason for adding client-side scripting first. State-switching applications for the viewer would then become trivial to write as a user process, in any language of the user's choice. We were working on such a design for the viewer within AWG many moons ago --- some details are given here, and the many advantages listed: https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft . We were also examining that kind of structure for user scripts in Imprudence: http://imprudenceviewer.org/wiki/Image:Plugin_system_flow_APIs.png . We're long past the refactoring sell-by date for this excessively monolithic client. The viewer is buggy as a direct consequence of its size and bloat --- there is no escaping that relationship in today's seat-of-pants software methodologies. Adding more things into the main code should be avoided at all costs, unless those things are central to its operation. Anything that is not central should be factored out into attached processes, and this is particularly true in the case of any facility that does not have a high speed requirement, such as your example. It would avoid bloat and be much more flexible. The right question to be asking at this stage is why Lindens are currently designing client-side scripting *behind closed doors* in their internal Firefly project. *Secrecy in design should have no place in an open source viewer.* In this instance it impacts directly on your suggestion, since state switching is so easy to do in an attached user script. I believe that Firefly should be stripped of its sekrit internal status and the design addressed here in this opensource-dev community, where it belongs. Given client-side scripting, adding a state machine into the core code would then become moot. Morgaine. == On Thu, Feb 11, 2010 at 4:59 PM, Aleric Inglewood < aleric.inglew...@gmail.com> wrote: > Hi, with the eye on supporting plugins, I'd like to add a 'tool' to the > viewer: > A state machine. > > I'd add a base class from which others can derive their own classes. > A new state machine would then be started by creating one or more objects > of those types. > > It would be a class that supports a chain of asynchronous actions (and > queries). > The object would run in the main thread and be called under the "Idle" > header (fasttimers). > The object will know an 'idle' state (when it's waiting for data) during > which it will > use no significant CPU. > > The user (developer, you) would provide an enum with states for your object > and switch between states by calling a method (ie, set_state(new_state)). > If it is necessary to wait, you can call the idle() method, which will idle > until data is available (detected elsewhere) causing the state machine to > continue the current state. > > As an example, consider a series of actions like walking to a certain > place, > creating a prim there (or rezzing something) and then sitting on it. Or, > wanting > to do some calculation on a number of selected prims (for which you have to > wait till all data of the selected prims has arrived). Well... the > applications are > limitless of course; just what plugins need ;). > > It won't be ALL that is needed for plugins, but it would be a good start, > because > this isn't wirrten/available before someone starts to write something for a > plugin, > the wheel will be reinvented over and over again. > > Any comments? :) > > Aleric > > > > > ___ > 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] State machine class
On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood < aleric.inglew...@gmail.com> wrote: > (sorry, but any 'secret' work that I never heard of before from whoever is > working on it on this list has to be ignored), Just because you haven't heard about something doesn't mean that others haven't. Lindens have mentioned their internal Firefly client-side scripting project at several of their Office Hours now, for example at Q Linden's. While the project name and purpose are known, the details are a closely guarded secret. This is highly inappropriate given that it will determine the structure of the open source viewer to which this list is dedicated. It's treating the opensource-dev community as nothing more than code and debug monkeys, dancing to the LL design tune. That's not a healthy relationship with open source communities. It's also out of step with claims that 2010 is going to see a new openness from Lindens. Firefly is a bad start. Client-side scripting is one of the most crucial features that the community should be discussing, because it will impact on almost everything about the viewer. It's massive. Morgaine. == The most important aspect of any non-trivial software system is its design, since that determines everything else. On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood < aleric.inglew...@gmail.com> wrote: > Morgaine, I *completely* agree with you! [?] > > One of the two main reasons, if not the only two, that we need this state > machine approach *is* for client-side scripting and for plugins. Both are > infinite flexible in nature and require in principle hooks into the viewer > code to *control* the viewer on a level that goes way beyond a blocking > function call. > > The best approach to look at this is the following: If we have to wait for > a server packet, it blocks. Currently there is no general way to wait for > server-packet-events, hence you *cannot* implement client-side scripting. > > The state machine is so core and so basic, it's the core at the basis of > much MORE code that is needed before you can even start to implement > client-side scripting. > > Thus, since it was always my main goal to use this for client-side > scripting (and sorry, but any 'secret' work that I never heard of before > from whoever is working on it on this list has to be ignored), I assume you > now agree with me that this would a great thing to have, since it will make > it possible, in the end to provide hooks into the viewer in The Right > Way(tm) that will allow us to write a client-side scripting implementation, > which in turn will allow plugins to be able to actually control the viewer. > > I don't HAVE client-side scripting yet, so I have written code that uses > this state machine on a higher level, but that was just to get a feeling of > what is needed. I think I'm now ready to write that base class. > > > On Mon, Feb 15, 2010 at 11:29 AM, Morgaine > wrote: > >> State machines are very useful, but the use case you gave is an example of >> a user application that should be coded in an attached script. The fact >> that the viewer does not yet have attached client-side scripting is not a >> reason for putting the user application directly into the viewer. It's a >> reason for adding client-side scripting first. >> >> State-switching applications for the viewer would then become trivial to >> write as a user process, in any language of the user's choice. We were >> working on such a design for the viewer within AWG many moons ago --- some >> details are given here, and the many advantages listed: >> https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft . We >> were also examining that kind of structure for user scripts in Imprudence: >> http://imprudenceviewer.org/wiki/Image:Plugin_system_flow_APIs.png . >> We're long past the refactoring sell-by date for this excessively monolithic >> client. >> >> The viewer is buggy as a direct consequence of its size and bloat --- >> there is no escaping that relationship in today's seat-of-pants software >> methodologies. Adding more things into the main code should be avoided at >> all costs, unless those things are central to its operation. Anything that >> is not central should be factored out into attached processes, and this is >> particularly true in the case of any facility that does not have a high >> speed requirement, such as your example. It would avoid bloat and be much >> more flexible. >> >> The right question to be asking at this stage is why Lindens are currently >> designing client-side scripting *behin
Re: [opensource-dev] State machine class
On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood < aleric.inglew...@gmail.com> wrote: > Morgaine, I *completely* agree with you! [?] > > One of the two main reasons, if not the only two, that we need this state > machine approach *is* for client-side scripting and for plugins. Both are > infinite flexible in nature and require in principle hooks into the viewer > code to *control* the viewer on a level that goes way beyond a blocking > function call. > > The best approach to look at this is the following: If we have to wait for > a server packet, it blocks. Currently there is no general way to wait for > server-packet-events, hence you *cannot* implement client-side scripting. > > The state machine is so core and so basic, it's the core at the basis of > much MORE code that is needed before you can even start to implement > client-side scripting. > **IFF** a state machine is required infrastructure in the viewer code before client-side scripting can be implemented, then I agree with you wholeheartedly. That claim has not yet been justified though. I would be * very* interested in seeing a design for client-side scripting that is based on a core state machine. The designs that I have been looking at do not require a state machine, because they use a stateless core. All state is maintained in the scripts themselves, and the viewer core doesn't need to be concerned with their state. It's much cleaner because the scripts can use normal blocking calls in normal languages --- all that comes for free with external processes, and benefits automatically from multiple cores. It's not the only way to skin a cat though, so I welcome discussion about alternative approaches. Assuming of course that Lindens open up the design process for client-side scripting in the first place ... Morgaine On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood < aleric.inglew...@gmail.com> wrote: > Morgaine, I *completely* agree with you! [?] > > One of the two main reasons, if not the only two, that we need this state > machine approach *is* for client-side scripting and for plugins. Both are > infinite flexible in nature and require in principle hooks into the viewer > code to *control* the viewer on a level that goes way beyond a blocking > function call. > > The best approach to look at this is the following: If we have to wait for > a server packet, it blocks. Currently there is no general way to wait for > server-packet-events, hence you *cannot* implement client-side scripting. > > The state machine is so core and so basic, it's the core at the basis of > much MORE code that is needed before you can even start to implement > client-side scripting. > > Thus, since it was always my main goal to use this for client-side > scripting (and sorry, but any 'secret' work that I never heard of before > from whoever is working on it on this list has to be ignored), I assume you > now agree with me that this would a great thing to have, since it will make > it possible, in the end to provide hooks into the viewer in The Right > Way(tm) that will allow us to write a client-side scripting implementation, > which in turn will allow plugins to be able to actually control the viewer. > > I don't HAVE client-side scripting yet, so I have written code that uses > this state machine on a higher level, but that was just to get a feeling of > what is needed. I think I'm now ready to write that base class. > > > On Mon, Feb 15, 2010 at 11:29 AM, Morgaine > wrote: > >> State machines are very useful, but the use case you gave is an example of >> a user application that should be coded in an attached script. The fact >> that the viewer does not yet have attached client-side scripting is not a >> reason for putting the user application directly into the viewer. It's a >> reason for adding client-side scripting first. >> >> State-switching applications for the viewer would then become trivial to >> write as a user process, in any language of the user's choice. We were >> working on such a design for the viewer within AWG many moons ago --- some >> details are given here, and the many advantages listed: >> https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft . We >> were also examining that kind of structure for user scripts in Imprudence: >> http://imprudenceviewer.org/wiki/Image:Plugin_system_flow_APIs.png . >> We're long past the refactoring sell-by date for this excessively monolithic >> client. >> >> The viewer is buggy as a direct consequence of its size and bloat --- >> there is no escaping that relationship in today's seat-of-pants software >>
Re: [opensource-dev] Fwd: State machine class
That's a very hard-wired approach, and it achieves nothing that cannot be
done much more simply and safely in user scripting processes. When things
go wrong with scripts, you don't want them going wrong in the core viewer.
A bad script running as an external process can simply be terminated ---
that's a much cleaner and safer approach.
What's more, your method handles only the simplest of state scripting
requirements directly, because the state switching conditions will
necessarily be of limited complexity and predefined in C++ code --- the
scripts themselves would have to set up more complex conditional triggers on
the fly by orchestrating multiple sub-states.
That is totally unnecessary, and a weak approach. If you let each script
maintain its own state in the normal manner for sequential programs, and
merely send it the events to which it has subscribed, then the script can
implement arbitrary conditional state switching very simply using
conventional programming.
Morgaine.
On Sun, Feb 14, 2010 at 11:27 PM, Aleric Inglewood <
aleric.inglew...@gmail.com> wrote:
> Ugh, seems this didn't go to the list... forwarding it there.
>
> -- Forwarded message --
> From: Aleric Inglewood
> Date: Mon, Feb 15, 2010 at 12:22 AM
> Subject: Re: [opensource-dev] State machine class
> To: Melinda Green
>
>
> I am already using it :p.
> This proposal is the direct result of practical experience, showing me that
> this is needed.
>
> But before I start to write example code that uses it, allow me to stay
> abstract.
>
> Didn't get much (other) reactions, so I thought I'd add some more details.
>
> The idea is to have objects that go through a series of (usually)
> sequential states:
>
> CONSTRUCTOR
> |
> v
>INIT
> |
> v
> custom states .
> .|
> .|
> .v
> custom states ->ABORT
> ||
> |<---'
> v
>DONE
>
>
> 'CONSTRUCTOR' would be an uninitialized state and never really executed
> (the 'state' variable during construction of the object). Obviously it
> would
> be in balance with it's destructor.
>
> 'INIT' would be the first state of the object when 'run'.
> If the whole finishes successfully, we end up in the state 'DONE',
> which cleanup in balance with INIT, and anything that is expected
> to be left over from going to the states successfully.
>
> The ABORT state is a state that will cleanup anything that might
> be left-over from an abort.
>
> The main thread ''runs' the object from it's 'Idle' state by calling
> gIdleCallbacks.addFunction(...) for this object.
>
> The main loop of such a StateMachine object would then look
> like something like:
>
> switch(mState)
> {
> case INIT:
> init();
> set_state(WAIT_FOR_FOO);
> case WAIT_FOR_FOO;
> if (!foo())
> idle();
> set_state(DO_MORE);
> case DO_MORE:
> do_it();
> set_state(WAIT_FOR_BAR);
> case WAIT_FOR_BAR:
> if (!bar())
> idle();
> set_state(DONE);
> case DONE:
> cleanup();
> }
>
> As you see, this gives a compact and clear code where the flow is intuitive
> (top down), but asynchronus and "blocking", without actually blocking the
> main loop.
>
> One of the major advantages is these objects are reusable; for example, one
> could write an object that checks if some inventory folder exists, if not
> creates it, and then (or when it already exists) waits till it's contents
> are available. Lets call this object SyncFolder(std::string const& name).
>
> Then another StateMachine object can use it (for example) as follows:
>
> class MyStateMachine : public LLStateMachine {
> SyncFolder mSyncFolder;
> ...
> virtual void init();
> virtual void abort();
> virtual void done();
> };
>
> void MyStateMachine::init()
> {
> mSyncFolder.set_name(folder_name);
> }
>
> bool MyStateMachine::mainloop()
> {
> // INIT, DONE and ABORT are handled by the base class.
> switch(mState)
> {
> case WAIT_FOR_FOO:
> if (!foo())
> idle();
> set_state(SYNC_FOLDER);
> case SYNC_FOLDER:
> if (!mSyncFolder()) // Returns true when DONE
> break;
> case REZ_ITEM_FROM_FOLDER:
> do_rez();
> }
> }
>
>
> One could create a large number of such objects that do simple tasks, and
> then use those to build
> objects that do more complex
[opensource-dev] Client-side scripting in Snowglobe
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 problematic on two related fronts: 1. Sandboxes by design do not allow most platform resources to be accessed, as a security measure. This is fine and important when scripts are being downloaded from unknown places (like Javascript in web pages), but that same protection also means that client-side scripts would be powerless to do useful things for us in concert with local applications, files, devices, etc. Sandboxing client-side scripts effectively hardwires in script weakness for no reason discussed as a requirement. 2. Sandboxed applications cannot be linked with user-chosen native libraries since allowing native code breaks sandbox protection. This means no accelerators, no extensions, and no interop with other systems since sockets are inaccessible from any strong sandbox. This also means no evolution or progress outside of what the sandbox designers permit. This mailing list is concerned with development of open source viewers, in particular Snowglobe. This is heralded as a *community* viewer, embodying * community* requirements much more directly than the LL mainstream viewer. Client-side scripting will impact on every single aspect of Snowglobe bar none, yet the community is being excluded from the design of its most powerful infrastructure element. This is entirely wrong, far beyond the normal observation that secrecy in design has no place in open source. It is hard to assess things technically when the design requirements are formulated in secret. The Snowglobe community has design requirements too. Those deserve to be examined here openly, not limiting Snowglobe to a design that stems from Linden requirements alone. 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
A line got lost from my post owing to finger trouble. Item 6 about Mono should have read: 6. Some parties identify other reasons for avoiding Mono in general. Without getting into that subject at all, requiring Mono for client-side scripting would make scripting unavailable to that portion of the user base. Since client-side scripting without Mono is perfectly feasible, Mono should not be made mandatory for scripting, so that the widest user base can be supported. Morgaine. On Thu, Feb 18, 2010 at 12:42 PM, 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 problematic on > two related fronts: > >1. Sandboxes by design do not allow most platform resources to be >accessed, as a security measure. This is fine and important when scripts >are being downloaded from unknown places (like Javascript in web pages), > but >that same protection also means that client-side scripts would be powerless >to do useful things for us in concert with local applications, files, >devices, etc. Sandboxing client-side scripts effectively hardwires in >script weakness for no reason discussed as a requirement. >2. Sandboxed applications cannot be linked with user-chosen native >libraries since allowing native code breaks sandbox protection. This means >no accelerators, no extensions, and no interop with other systems since >sockets are inaccessible from any strong sandbox. This also means no >evolution or progress outside of what the sandbox designers permit. > > > This mailing list is concerned with development of open source viewers, in > particular Snowglobe. This is heralded as a *community* viewer, embodying > *community* requirements much more directly than the LL mainstream viewer. > Client-side scripting will impact on every single aspect of Snowglobe bar > none, yet the community is being excluded from the design of its most > powerful infrastructure element. This is entirely wrong, far beyond the > normal observation that secrecy in design has no place in open source. > > It is hard to assess things techn
Re: [opensource-dev] Client-side scripting in Snowglobe
Kent, it is true that Office Hour discussions can sometimes get a bit heated because of the format, which allows little time for careful consideration and reflection before writing, but that is not the case here. My opening post above was polite and factual, and it considered all the points that have been revealed to us. Please do not make blanket accusations about flaming as an excuse for keeping the project under wraps, when my goal in the thread is collaboration. Quite the opposite of flaming, I am trying to bring into the open here some very key issues of viewer design that will directly affect the Snowglobe community branch of the viewer in numerous far-reaching ways. That discussion belongs here, not in informal chat at Office Hours which is a completely inappropriate medium for technical design. Re your closing line: On Thu, Feb 18, 2010 at 3:57 PM, Kent Quirk (Q Linden) wrote: > I'm afraid the tone and direction of this discussion are making it > impossible for us to talk about this project productively. > The direction of this discussion is towards involving the Snowglobe community in the design process for their viewer. The tone of this discussion is (speaking for myself) polite. I see no reason why you would not wish to talk about the design of client-side scripting with us, very productively. Morgaine. On Thu, Feb 18, 2010 at 3:57 PM, Kent Quirk (Q Linden) wrote: > This makes me sad. > > I've been trying to have an open discussion about some of the design issues > in my office hours, specifically to understand the constraints and > requirements of the community. But every office hour seems to be followed up > by flames on this list and in other forums interpreting what was said in the > worst possible way. > > I'm afraid the tone and direction of this discussion are making it > impossible for us to talk about this project productively. > > Q > > > On Feb 18, 2010, at 7:42 AM, 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 problematic on > two related fronts: > >1. Sandboxes by design do not allow most platform resource
Re: [opensource-dev] Client-side scripting in Snowglobe
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 fundamental requirement: the sandbox must be optional, applying only to the use case of unknown downloaded scripts, and not applying when the user wishes her scripts to be used as an interface to local facilities. It is considerations such as this that Lindens should be exploring together with the community here, because it impacts on the future of Snowglobe directly and in a colossal way. We are all affected. Designing this behind closed doors is not adequate, nor is it appropriate in an open source community viewer. Morgaine. == On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble wrote: > I haven't been following this topic in any office hours so I hope my > comments aren't too off base. > > Personally I'd prefer to be able to run extensions as sandboxed, and maybe > have the option of running them unprotected on a per-extension basis. 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). > > Concerning Morgaine's list: while I may not fully agree with reasons 1-4, > they appear to reflect valid concerns and are presented in a agreeable > manner. Reasons 5 and 6 seem to imply political overtones to me, and I > suspect any platform choice will carry some political burden with it. > Personally I believe mono to be a reasonable choice for a scripting > environment, especially given LL's experience with it in their servers. > > And now since I don't contribute to the LL viewer source, I'll shut up :) > > -d > > > On Thu, Feb 18, 2010 at 4:57 AM, Morgaine > wrote: > >> A line got lost from my post owing to finger trouble. Item 6 about Mono >> should have read: >> >> >> 6. Some parties identify other reasons for avoiding Mono in general. >> Without getting into that subject at all, requiring Mono for client-side >> scripting would make scripting unavailable to that portion of the user >> base. Since client-side scripting without Mono is perfectly feasible, Mono >> should not be made mandatory for scripting, so that the widest user base can >> be supported. >> >> >> Morgaine. >> >> >> >> >> >> >> >> >> On Thu, Feb 18, 2010 at 12:42 PM, Morgaine < >> morgaine.din...@googlemail.com> 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, w
Re: [opensource-dev] Client-side scripting in Snowglobe
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, here<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000109.html>and here<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000116.html> . 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
Re: [opensource-dev] Client-side scripting in Snowglobe
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<http://imprudenceviewer.org/wiki/Image:Plugin_system_flow_APIs.png>. 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
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 eff
Re: [opensource-dev] Client-side scripting in Snowglobe
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 cl
Re: [opensource-dev] Client-side scripting in Snowglobe
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. > > > > > ==
Re: [opensource-dev] Client-side scripting in Snowglobe
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
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
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
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
Thanks Kitty for that correction. :-) Accurate naming and attribution may not be world-shattering issues, but that's no reason for getting them wrong, and I am glad you took the time to put the record straight. :D /me waves to Kitty and Marine :-) Morgaine. == I certainly had no intention of misrepresenting anything, and mistakenly assumed that the 'a' of RLVa actually referred to "API" rather than "alternate". On Sat, Feb 20, 2010 at 2:36 PM, Kitty wrote: > >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. > > Slight little correction here: RLVa is solely an (alternate) implementation > of the RLV API. While I am responsible for coding RLVa, Marine is > responsible for her original RLV implementation and more fitting for this > topic she's responsible for the actual RLV API/specification. > > Since it's used here to refer to the actual API it would be the "RLV API" > rather than "RLVa API". > > Silly for most anyone I'd imagine, but little things like that tend to > obscure the origin and credit should go where the credit is due so I just > wanted to clear that up :) . > > Kitty > ___ 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, I'll just add one specific point to Lawson's broader treatment. In the fully factored out Multi-Process Client design<https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft>that we were working on back in the days when AWG did such things, the various processes were attached by sockets and communicated by messaging because that provides the largest amount of decoupling between modules, harnesses the power of multicore with minimal effort, and avoids almost all the pitfalls of concurrent programming with mutable shared state. It's also easy to debug. Although local sockets are easily fast enough for the majority of scripting uses within a VW client, there are a few areas where you want to hit the metal at the fastest possible rate, such as rendering. To cater for this, the design allowed "Facility optimization" or "accelerators" to be defined: in most cases this would mean that two communicating processes would negotiate a shared memory segment for their private use, and eliminate any communication bottleneck between them by using direct memory reference. This approach avoids *premature optimization*: you add an accelerator to a socket link only when profiling tells you that a particular task is suffering from socket throughput or latency issues. In addition, it provides a reference model for functionality: your accelerator should modify only the *speed* of interactions between two processes, and not the semantics. Any unit tests that worked through sockets alone should continue to work with the accelerator enabled, just faster. Transparent acceleration gives you a huge development win. That said, the Multi-Process Client is only vaguely related to the design that we're discussing for client-side scripting in this thread. The viewer is not being redesigned from scratch (as far as we know), and hence a full decomposition along these lines is not in the realm of possibilities. Instead, we have in mind a rather minimalist messaging interface within the viewer, the bare minimum that would allow a message sent by a scripting process to activate a function in the viewer, plus the inverse operation, viewer callbacks that respond to viewer events by sending a message to any script process interested in the event. Despite the minimalism, it is worth noting that the "accelerator" approach of the Multi-Process Client still applies here. There is no reason why an attached script process could not open a dedicated shared memory segment and cooperate with the viewer in very high speed operations, including graphics rendering. It is interesting to hear that you also had this kind of communications architecture in mind. I think perhaps it's an applications model whose time has finally arrived, the age of multicore. Morgaine. = On Sat, Feb 20, 2010 at 6:27 AM, Lawson English wrote: > 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
Re: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe
Carlo, I agree completely with you on the principle of the implementation. On the terminology, not only are you not being logical in your naming, but you also immediately contradict yourself and demonstrate beautifully how your suggested naming makes no sense at all, not even to yourself. Let me demonstrate: On Sun, Feb 21, 2010 at 10:45 AM, Carlo Wood wrote: > It seems to me that most people still talk about untrusted, > portable, and grid-wide supported downloadable scripts when > talking about Client-side scripting (sorry Morgaine). > > So, I propose to go with that, and call anything else > "Client-extensions". > > So here you've said that "Client-extensions" are not "Client-side scripting". And then you follow that with: > The remainder of this post is about Client-extensions. > ... > Plugin(s) > > > One or more plugins then could provide a client-side > scripting engine; either for trusted for any language, > or a secure API for an engine running the mono bytecode > that LL is working on (or whatever). > And here you've said that Plugin(s) provide a "client-side scripting engine", in other words, an engine that does client-side scripting. Thank you for showing so clearly that both types are "client-side scripting". :-))) As I've been saying all along, anything that does scripting on the client is "client-side scripting". Any other interpretation is going to confuse the hell out of newbies, and as you've shown yourself, even the experts will not be immune to the confusion it creates. :D We can of course choose a couple of different words to disambiguate between the two types. That would be useful. I like the phrase "Client Extensions" for the trusted installed scripts a lot! But you can't say that one of them isn't "client-side scripting", when in both cases the scripts run on the client. What's more, those of us who will be writing our extensions will be scripting our clients. You can't eliminate that phrase, it won't work. I really don't want to belabor this point any further, because it's getting silly. But on the implementation side, yes, this is a good topic, and you're describing a model similar to the one that Argent and Dzonatas and Sai and I and others have proposed. Morgaine. On Sun, Feb 21, 2010 at 10:45 AM, Carlo Wood wrote: > It seems to me that most people still talk about untrusted, > portable, and grid-wide supported downloadable scripts when > talking about Client-side scripting (sorry Morgaine). > > So, I propose to go with that, and call anything else > "Client-extensions". > > --- > > The remainder of this post is about Client-extensions. > > I sense consensus on the following layered design: > > [current code base] > > + lots of hooks to be written > > | > | > V > > C++ API [1] > > | > | > V > > IPC API [2] > > | > | > V > > Plugin(s) > > > One or more plugins then could provide a client-side > scripting engine; either for trusted for any language, > or a secure API for an engine running the mono bytecode > that LL is working on (or whatever). > > - A scripting engine for language XYZ. > > [1] Ie, based on the yet to be written LLStateMachine class. > [2] Ie, a socket. What is more important is the protocol >that is being used here. I can imagine that this will >be LLSD, or something simular. > > -- > Carlo Wood > > PS Note that personally I'm against using mono for > clientside scripting... > > ___ > 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] Consensus? was: Client-side scripting in Snowglobe
Dzon: Nice parable. :-) The moral of the story as it pertains to our topic is that when the superset is ambiguous as in our case (all scripts running client-side are naturally "client-side scripts"), then the ambiguity won't stop until you subset the space into disjoint subsets so that you can discuss each subset separately without confusion. That's what I've been trying to do, because "client-side script" is a universal term that naturally denotes all scripts running in the client by simple plain English, so you can't call just one subset of the scripts by that name without creating ambiguity. To remove the ambiguity, I split the space of all scripts that run client-side into two disjoint sets (note that we are using "scripts" and "programs" interchangeably here): - *Trusted / Installed / Not-sandboxed*: These are scripts which you trust enough to install on your machine, and which typically act as interfaces between the viewer and your local resources, such as your files, applications, I/O devices, and so on. Because they interface to local resources, these scripts cannot run in a sandbox. In general, these scripts are for user empowerment --- they can do anything the user wants them to do, and therefore a very good term for them is "*client extensions*". A large number of accessibility scripts fall into this category, as well as scripts for implementing new detached windows such as multi-screen chat and inventories stored on the PC. - *Untrusted / Not-installed / Sandboxed*: These are scripts which you do not trust because they arrived by some automatic mechanism, possibly from in-world. They are never installed, but run in a protective sandbox while needed, and disappear automatically when no longer needed. Because they run in a sandbox to (hopefully) protect your machine from malicious code, these scripts can never access your local resources, as that would be extremely dangerous. In general, these scripts are not for user empowerment, but for enhancing or assisting the displayed content from the current virtual world in some way. A possible term for them is therefore "*world extensions*". This kind of script can implement interesting HUDs using in-world data obtained from the viewer, or new in-viewer windows, menus and improved viewer inventory. A separate question is whether it is wise to allow untrusted scripts to run on your client at all, given that there will always be bugs and protection failures, especially in the first few years. But that is a topic for a later discussion I think, given that currently we have not yet managed to open a dialogue with Lindens about client-side scripting at all. Morgaine. === On Mon, Feb 22, 2010 at 12:57 AM, Dzonatas Sol wrote: > Morgaine wrote: > >> Carlo, I agree completely with you on the principle of the implementation. >> >> On the terminology, not only are you not being logical in your naming, but >> you also immediately contradict yourself and demonstrate beautifully how >> your suggested naming makes no sense at all, not even to yourself.� Let me >> demonstrate: >> >> >> > One of Linden Lab's disqualifiers on attempts to be hired had to do with a > coin placed on any surface and the game of prediction of who would win based > on who placed the last coin on the surface where there was room left over. > > They go through a bunch of different kinds of objects, so I won't name them > off so they can still use the fair ones. > > However, there was one they were beautifully wrong about: the sphere. > > They even called people "stupid" on the spot who couldn't figure out the > sphere ended up with even amount of moves. Long story short about... stupid. > > We could challenge this since somehow it became more than personal, or > maybe it was meant to be challenged eventually. It wasn't their standard > procedure whatever it was. > > If we take a perfect sphere with a perfect surface, there is an obvious > flaw that wouldn't allow it to be even in number of moves. > > When LL said "here is a sphere the size of a quarter in diameter... 1 2 3 4 > 5 6" as one points top, bottom, left, right, back, front. And says "Stupid" > with a superiority look. > > Obviously the person that was challenged, the one to be hired, said "Odd." > > If you know if it is "even" or "odd" then you know who gets the last move, > and wins. > > Further on the surface about a perfect sphere, if it diameter is perfect no > matter what tangent coordinate picked out on the surface, then the surface > could be eventually said it is infinite. Ther
Re: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe
On Mon, Feb 22, 2010 at 11:56 PM, Carlo Wood wrote: > There is no need for A != B. > > Why not define the words A and B such that A includes B? B \in A > > Then you can still talk about the subject, since there is still a C = A > \not B, > such that the intersection of B and C is empty. > For the simple reason that in our case there is no C = A \not B, because A is the set of all scripts that execute client-side, and that includes all the possible types of scripting/programming that we are discussing here: they are all subsets of A. > > In other words, yes Client-Extensions include plugins that implement > Client-side scripting, but it won't give confusion because if someone means > that, they will say "Client-side scripting", so if they DON'T say that, > they probably mean something else, either something broader (including > client-side script plugins) or something entirely different even. Except that there is no possibility of avoiding confusion your way, because when people write scripts that execute in the client, they will unavoidably call it client-side scripting. It's totally unavoidable because it's normal use of English. It's also normal use of the word "scripting" in numerous language communities --- for example, Lua and Perl and shell programmers always talk about their Lua scripts and Perl scripts and shell scripts, regardless of the application, and it's doubly prevalent when the scripting language is used embedded in a host application because then it distinguishes the script program from the host program. This use of "scripting" is pervasive throughout computing's many language communities. That's not going to change, so rather than trying to sweep back the tide and stopping people saying that they're doing client-side scripting when they're programming client extensions, it's easier to accept that people will always call scripting "scripting" wherever it is being applied, and invent two new disjoint terms instead. It's also worth adding to this Tigro Spottystripe's observation<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000175.html>that a control panel that provides information and control over script properties, resourcing, protection, and so on, is applicable to all kinds of scripts, regardless of where they come from and what role they play. Even just thinking about such practical areas alone, there is a push for commonality. It's not even totally black and white that there *are* two separate categories. One could easily envisage a system where the user controls what local facilities are made accessible to a sandbox per script, so that it's not "all or nothing" like we've been describing up to now. Even trust is not a black and white thing, and nor is installation --- scripts loaded automatically could be cached for longer-lived retention, or even retained forever. Tigro's suggestion is interesting. There really is a continuum here. Morgaine. === On Mon, Feb 22, 2010 at 11:56 PM, Carlo Wood wrote: > There is no need for A != B. > > Why not define the words A and B such that A includes B? B \in A > > Then you can still talk about the subject, since there is still a C = A > \not B, > such that the intersection of B and C is empty. > > In other words, yes Client-Extensions include plugins that implement > Client-side scripting, but it won't give confusion because if someone means > that, they will say "Client-side scripting", so if they DON'T say that, > they probably mean something else, either something broader (including > client-side script plugins) or something entirely different even. > > On Mon, Feb 22, 2010 at 04:51:20AM +, Morgaine wrote: > > The moral of the story as it pertains to our topic is that when the > superset is > > ambiguous as in our case (all scripts running client-side are naturally > > "client-side scripts"), then the ambiguity won't stop until you subset > the > > space into disjoint subsets so that you can discuss each subset > separately > > without confusion. > > > > That's what I've been trying to do, because "client-side script" is a > universal > > term that naturally denotes all scripts running in the client by simple > plain > > English, so you can't call just one subset of the scripts by that name > without > > creating ambiguity. > > -- > 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] Third party viewer policy
Gigs is totally right that http://secondlife.com/corporate/tpv.php is completely incompatible with the GPL. Specifically, TPV clause 1c is incompatible with GPLv2 clause 6. GPLv2 has a FAQ that elaborates on this point, highlighting from clause 6 that: - "*You may not impose any further restrictions on the recipients' exercise of the rights granted herein.*" TPV 1c adds massive further restrictions on Developers that fall under the condition of "*If you are a Developer who distributes Third-Party Viewers to others".* Please note the word "*distributes*" in the condition above, because it is crucial. GPLv2 is a *distribution license*, in other words it triggers at the point of distribution of GPL-licensed code. The freedoms that GPLv2 grants apply at that specific point in time, allowing a developer to *distribute* his code freely downstream to the next recipient, who can then modify the code again and *distribute* it to others downstream, and so on. It is this distribution that TPV 1c specifically entangles with a mass of restrictions. This cannot be done with the GPL of any version. TPV is dramatically GLPv2 non-compliant. I fully expect that LL did not intend to make TPV 1c apply so broadly and to be GPL non-compliant. Rather than this being intentional, it's more likely (I think) that the document was drafted by someone not very good at legal language and ignorant of the GPL. Unfortunately, the words stand as written, so unless they are rewritten, no Linden-derived viewer will be distributable under GPL. GPL cannot be used to grant fewer freedoms than the GPL specifies. Lindens are of course entirely within their rights to determine how their service is used. What they cannot do is use the GPLv2 license while at the same time imposing on the developer "*further restrictions on the recipients' exercise of the rights granted herein.*" Morgaine. === On Tue, Feb 23, 2010 at 8:16 PM, Gigs wrote: > http://secondlife.com/corporate/tpv.php > > You all realize this is massively incompatible with the GPL, right? > > > ___ > 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] Third party viewer policy
Soft, Please add to your list of issues to pass to Legal, a highlighted copy of Clause 6 in the GPLv2 license<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>, as well as a highlighted copy of the section of the GPLv2 FAQ<http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html>which addresses the relevant clause of the license with a clear example of GPL non-compliance. [Search for "*impose any further restrictions"* to find it]. TPV <http://secondlife.com/corporate/tpv.php> section 1c is dramatically incompatible with GPLv2 clause 6 because it conflicts with this part of clause 6 (an extremely important term in all GPL licenses), in the specific case where the "recipient" of the code is the developer: - "*You may not impose any further restrictions on the recipients' exercise of the rights granted herein.*" I fear that LL Legal may still not get the point that this has *absolutely nothing to do with access* to the SL service --- the GPL is not concerned with that, and the "restrictions" mentioned in clause 6 are unrelated to service access. They are concerned exclusively with restrictions on the developer's freedom to *modify and distribute GPL programs*. Modification and distribution of GPL-licensed programs are guaranteed by the GPL to be free of any restrictions not mentioned in the GPL license. A party that imposes additional restrictions (or conditions) on the freedom of a developer to modify and distribute code may not use GPLv2 as their license. If LL wishes to continue using the GPL, they will need to remove the restrictions and conditions that TPV currently imposes on the developer, and (presumably) replace them by restrictions on access to the service by the users of the software instead. It worries me that this key point about the GPL will not get across to Legal, given that they clearly failed to comprehend the GPL when drafting TPV. Please do your best to help them understand this issue. Morgaine. == On Wed, Feb 24, 2010 at 9:21 PM, Soft Linden wrote: > On Wed, Feb 24, 2010 at 2:47 PM, Marine Kelley > wrote: > > > > But what I am concerned about is the viewer directory. I see that I need > to > > provide my RL info to list my viewer there, and that this RL info would > then > > be visible to all for liability. > > I'm putting together a list of concerns for more discussion with > legal; I'll add this to the list. > ___ > 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] Consensus? was: Client-side scripting in Snowglobe
Only in your ambiguous definition, which I've already debunked. Morgaine. On Thu, Feb 25, 2010 at 12:00 AM, Carlo Wood wrote: > On Tue, Feb 23, 2010 at 03:10:55PM +, Morgaine wrote: > > For the simple reason that in our case there is no C = A \not B, because > A is > > the set of all scripts that execute client-side, and that includes all > the > > possible types of scripting/programming that we are discussing here: > they are > > all subsets of A. > > No, A (client-extension) is all plugins, and B (client-side scripting) > is all untrusted client-side scripting. > > -- > 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] Third party viewer policy
Good points, Boy Lane, concerning developer liability not being acceptable. But it goes even further than that. Developer liability is *not GPLv2 compliant*. Here are GPLv2 <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>'s "*NO WARRANTY*" clauses: QUOTE *NO WARRANTY* *11.* BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. *12.* IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END QUOTE All liability and responsibility for the use of a GPL program rests with the users of the program, not with the developer of the program. This is an explicit condition of all GPL licenses, and these licenses cannot be employed by LL if section 7 of the TPV document is valid. It is worth noting that the BSD license also has a similar NO WARRANTY clause to protect its developers. Morgaine. == On Thu, Feb 25, 2010 at 4:18 AM, Boy Lane wrote: > I would like to reiterate on one point that was mentioned shortly > already, the liability of a developer. > > LL's new policy says under 7. > > "If you are a user or Developer of Third-Party Viewers: > > a. You are responsible for all uses you make of Third-Party Viewers, and if > you are a Developer, you are also responsible for all Third-Party Viewers > that you develop or distribute." > > In it's current form that reads: a developer is fully legally responsible > for the code, and in addition to that also carries full responsibility for > any user action of anyone using that viewer. In my opinion that's a killer > clause nobody halfway intelligent can accept. > > In detail, this clause has two major implications. > > Firstly by accepting 3PVP a developer would have to take full > responsibility for the viewer and the code it is based on. We all know that > these sources were developed by hundreds of different people and contain > hundreds if not thousands of known and unknown bugs (not sure about actual > Jira statistics). LL itself declines any responsibility in the sourcecode by > sating "ALL LINDEN LAB SOURCE CODE IS PROVIDED "AS IS." LINDEN LAB MAKES NO > WARRANTIES, EXPRESS, IMPLIED OR OTHERWISE, REGARDING ITS ACCURACY, > COMPLETENESS OR PERFORMANCE." Now LL forces a 3rd party viewer developer to > take on exactly that responsibility LL explicitly disclaims. I as a > developer can not accept this as I'm simply unable to guarantee that the > underlying code is 100% failure free or that there are no exploits possible > to abuse that code. Nobody can guarantee this and therefore should limit > ones liability to either the value of the software itself, here free > open-sourced code with a value of zero; or completely disclaims any > responsibility as it is the current status of the viewer code. > > Secondly and worse than the first point, by accepting the policy I'd also > automatically take on full responsibility for anything a user does with the > viewer. Be it using build in features (abuse, harassment, griefing, you name > it), or furthermore use exploits in the code for not only malicious > activities. No developer ever could control or prevent any user action and > should never be held responsible for any action a user does with the > software provided. > > I fully agree that a certain level of accountability is necessary. LL has > already all means to implement such accountability by having RL details of > each developer that is connected to an avatar. That's what the ToS warrant. > As such LL is already enabled to identify and prevent access of malicious > viewers and creators behind. The current liability clause therefore goes way > to far, is unfeasible, and renders the complete policy
Re: [opensource-dev] Third party viewer policy
That's good to hear, Soft, thanks. Please also make Legal aware of the impact of GPLv2's "NO WARRANTY" section to avoid yet another cause of GPL non-compliance through imposing conditions and liabilities on developers. I've listed it here<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000309.html>following on from Boy Lane's good points about liability. Apparently a large amount of the confusion you mentioned is due to the TPV being addressed to developers and users *simultaneously*, as one Linden suggested today. Clearly this mixing doesn't work, and is the reason for multiple areas of GPL non-compliance in the TPV. I hope that a very clear distinction between developers and users is forthcoming in the next revision and FAQ, so that the GPL can continue to be used. Morgaine. === On Thu, Feb 25, 2010 at 12:12 AM, Soft Linden wrote: > On Wed, Feb 24, 2010 at 4:30 PM, Morgaine > wrote: > > Soft, > > > > Please add to your list of issues to pass to Legal, a highlighted copy of > > Clause 6 in the GPLv2 license, as well as a highlighted copy of the > section > > of the GPLv2 FAQ which addresses the relevant clause of the license with > a > > clear example of GPL non-compliance. [Search for "impose any further > > restrictions" to find it]. > > > > TPV section 1c is dramatically incompatible with GPLv2 clause 6 because > it > > conflicts with this part of clause 6 (an extremely important term in all > GPL > > licenses), in the specific case where the "recipient" of the code is the > > developer: > > > > "You may not impose any further restrictions on the recipients' exercise > of > > the rights granted herein." > > Legal doesn't intend this to be a restriction on anything but use of > our service or eligibility for inclusion in the Viewer Directory. > Context is important here. Even the maintainers of GNU telnet won't > let someone use telnet to mess up the FSF's servers. > > Legal is aware that there has been confusion on this. There will be an > update soon, which makes the terms more clear. > ___ 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] "Resposibility" - Third party viewer policy
Colin, there is a problem in the way that you are reading the TPV. You are using commonsense. That is not how law works. It deals in what is actually written down. And what is written down is not commonsense. The actual words in the TPV, separate from any sane person's interpretation of what they SHOULD refer to, *explicitly state* that a developer must do X, Y, Z in order to be allowed to distribute her modified GPL program, and that is incompatible with GPLv2 (in fact, with all versions of GPL). One Linden defined the problem very well in group chat yesterday: The TPV talks about developers and users *simultaneously*, which causes confusion, and as a result of that confusion there are restrictions imposed on developers which should apply only to users. It is those restrictions, which are very sensible when applied to users, that are not GPL compatible when applied to developers, because they are an additional restriction on the GPL-granted freedoms to modify and distribute a GPL program. Such additional restrictions are expressly forbidden by GPLv2 clause 6. Apparently those restrictions on developers were not intentional. The TPV should never have been written by someone who doesn't understand deeply the details of the GPL and who does not have a good command of legal-type language, which requires high precision in wording. They didn't even understand the meaning of "NO WARRANTY", written in capital letters in the GPLv2 license. Allegedly that's the only problem with the TPV, an incompetently written document, not evil intent. Of course there is also the insanity of Linden Lab trying to claim trademark domain over the word "Life". For that, the Linden lawyers deserve nothing but a good kicking. (Do it now!) Just because lawyers throughout the US behave like idiots doesn't mean that Linden lawyers must follow in the footsteps of idiocy. Morgaine. === On Thu, Feb 25, 2010 at 6:30 PM, Colin Kern wrote: > On Wed, Feb 24, 2010 at 10:35 AM, Vex Streeter > wrote: > > > > GPL also specifically disclaims warranty and liability unless you choose > to > > provide such for your code or distribution. Policy sections 1.c.i and > > 1.c.ii are redundant w/rt GPL but_requiring_ such statements of > downstream > > distributors conflicts with GPL. Policy section 7.d is even worse as it > > directly contradicts GPL liability disclaimers. > > > > Nothing in the TPV contradicts or violates the GPL, because the GPL is > all about distribution of software, and the TPV is about whether or > not LL will allow a viewer to connect to their servers, not whether > you'll be allowed to distribute it. > > Colin > ___ > 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] "Second-Party" viewer policy (was: Third party viewer policy)
Careful with the wording, Soft. :-) [Bad wording is the reason for much of this thread, sadly.] You didn't actually mean, I hope: "Most apply to any third-party viewer however, even if you aren't distributing it." What you meant was, I hope: "Most apply to any third-party viewer when that viewer connects to the SL service, even if you aren't distributing it." Legally, there is a world of difference. The original wording applies also when the third party viewer is used to connect to Opensim, for example, which you have no legal power nor community-friendly reason to restrict. We don't usually need to speak with mind-numbing precision, and can rely on context for brevity, but that absolutely does not work in the current subject with its legal ramifications. These dratted words, they're such a pain. Instead of saying what we mean, they say what they say. :D Morgaine. = On Thu, Feb 25, 2010 at 10:29 PM, Soft Linden wrote: > On Thu, Feb 25, 2010 at 3:37 PM, Jay Reynolds Freeman > wrote: > > > > But what if there is no "third party"? What if I develop a modified > version of the SL viewer all by myself, and use it to log in to the SL > servers, but do not distribute either source or binary for it? Since there > is no additional, "third" party involved in the creation and use of this > viewer, it would appear that nothing in the "Linden Lab Policy on > Third-Party Viewers" applies to it or to me. > > > > The FAQ and revised TPV, coming soon, will address this directly. > There are some terms in there that don't apply if you aren't putting > the viewer in the registry, and they will be identified as such. Most > apply to any third-party viewer however, even if you aren't > distributing it. > ___ > 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] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses
Argent, now that you mention GPLv3, it's worth pointing out that if LL relicensed their sources to GPLv3 then they would be prevented from suing GPL developers for patent infringement (under fear of loss of GPL rights), because of GPLv3's patent retaliation clause. That would remove one source of worry that projects like Opensim currently believe they have. Morgaine. On Fri, Feb 26, 2010 at 2:50 AM, Argent Stonecutter wrote: > Gigs... I think what you're looking at is akin to Tivoization, and > providing an external source for Tivoized content is compatible with > GPL2 (and is one reason for the GPL3). > ___ > 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] FAQ posted for Third Party Viewer Policy
u to respect those rights*." Respecting their rights in this case requires you to to allow that content to be exported as its creator desires. Therefore you either need to extend A15 with this additional case, or add another FAQ Q+A (preferably immediately after #15) to address it. I'm limiting my interest to the open source / licensing aspects of TPV and FAQ so some of the Q+As I've skimmed only superficially, but they seem fairly reasonable. There are also some entries that refer to the forthcoming TPV document, so substantive comment now would not make sense. FAQ.3 is worrying though --- it hints that the TPV may list further restrictions on the GPL developer's freedom to modify and distribute, again in direct contravention of GPLv2 clause 6. Morgaine. = On Sat, Feb 27, 2010 at 3:14 AM, Soft Linden wrote: > There's now a FAQ for the Linden Lab Policy on Third Party Viewers: > http://bit.ly/caedse > > This addresses many of the questions and concerns made in > opensource-dev and elsewhere. An updated version of the TPV doc itself > is also coming, but expect this within a couple weeks. Go visit the > FAQ, or read on for the TPV doc update details... > > I know that the member of the legal team who owns the policy doc is > still working over the final version. Linden Lab has approached > outside legal experts with your feedback, and one of these experts is > a lawyer who specializes in open source license compliance issues. > Based on these experts' feedback and further internal review, our > legal department will incorporate any required changes. > > In the meantime, while it helps to start making changes now, parts of > the policy are not yet in effect. See the tail of the FAQ for dates > and the portions affected. > ___ > 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] [Fwd: [realXtend] Presentation of naali viewer and realXtend to AW Groupies...]
This is great, Lawson. Many thanks for setting it up! Morgaine. == On Fri, Feb 26, 2010 at 9:33 PM, Lawson English wrote: > For anyone who has an interest in SL viewers that are not part of the > Linden Lab GPL tree, we've invited developers from the realXtend project to > make a presentation to the AW Groupies this Tuesday at 8:30 AM SLT (to allow > for a rather large time zone difference). > > http://www.realxtend.org/ > > > We are hoping to have a large, technically minded (for the most part) > audience who are prepared to ask tough questions. Non-techies are certainly > welcome to come and ask questions as well. The topic should be about both > programming and non-programming issues. > > IM me, Saijanai Kuhn, in-world sometime before the meeting in order to get > a group invite to get to the island. Zha generally opens the island to > non-members during these presentations, but in case something goes wrong, > its easier to be part of the group, at least during the meeting. That way > you can participate in the group chatter as well. > > > That will be 8:30AM SLT this coming Tuesday. 6:30 PM EET. > > at http://maps.secondlife.com/secondlife/ThorneBridgeTown/156/129/24 > > > > > This was sent to the realXtend list: > > Toni has said he can make it to the Groupies meeting this coming Tuesday at > 8:30 AM SLT (6:30 PM EET I believe) and Zha Ewry says she can ensure it will > be available at that time. > > It would certainly be great to have more than one person there from > realXtend. When we invited the Open Cobalt team, we ended up asking enough > questions to overwhelm just one person. > > Also, whoever comes should understand that the range of questions is HUGE: > we have people who use SL for education and handicap-access that might be > attending. Likewise, the metanomics team sometimes attends. Other viewer > developers are often around, as well as Lindens and contributors to OpenSim > from IBM and so on. If I work on it, I can probably fill up the sim (80 > avatars) with interested people with enough background to ask decent > questions, both about the programming and your long-term plans for how > realxtend might be used. > > > > So anyone who wants to attend and help answer questions about naali and > realxtend should feel free to give me (Saijanai Kuhn) an IM in Second Life > so I can invite you to the island for the presentation. > > > That will be 8:30AM SLT this coming Tuesday. 6:30 PM EET. > > at http://maps.secondlife.com/secondlife/ThorneBridgeTown/156/129/24 > > > Hope to see you all there. > > > Lawson English (Saijanai Kuhn in Second Life) > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org > > Toni has said he can make it to the Groupies meeting this coming Tuesday at > 8:30 AM SLT (6:30 PM EET I believe) and Zha Ewry says she can ensure it will > be available at that time. > > It would certainly be great to have more than one person there from > realXtend. When we invited the Open Cobalt team, we ended up asking enough > questions to overwhelm just one person. > > Also, whoever comes should understand that the range of questions is HUGE: > we have people who use SL for education and handicap-access that might be > attending. Likewise, the metanomics team sometimes attends. Other viewer > developers are often around, as well as Lindens and contributors to OpenSim > from IBM and so on. If I work on it, I can probably fill up the sim (80 > avatars) with interested people with enough background to ask decent > questions, both about the programming and your long-term plans for how > realxtend might be used. > > > > So anyone who wants to attend and help answer questions about naali and > realxtend should feel free to give me (Saijanai Kuhn) an IM in Second Life > so I can invite you to the island for the presentation. > > > That will be 8:30AM SLT this coming Tuesday. 6:30 PM EET. > > at http://maps.secondlife.com/secondlife/ThorneBridgeTown/156/129/24 > > > Hope to see you all there. > > > Lawson English (Saijanai Kuhn in Second Life) > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org > > > ___ > 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] FAQ posted for Third Party Viewer Policy
Fleep, you give an excellent example highlighting the needs of Education in this area. Given the huge interest in educational content both in SL and in Opensim-based grids such as Science Sim, this is certain to be of major and growing interest. Perhaps the FAQ could add a *new* clause FAQ.16 (renumbering the old FAQ.16 and all subsequent ones down) which reads something like this: - Q16: Are the rights of open source or open content providers respected? - A16: Yes. To further protect the rights of content creators beyond FAQ.15, Linden Lab also respects the wishes of creators who release their content under open source or open content licenses to make their content freely exportable. (Typical licenses are GPL, BSD, or Creative Commons.) The responsibility for ensuring that such content does not contravene FAQ.15 rests entirely with the licensor, who must ensure that all parts either comply with FAQ.15 or have been released under an open license by their respective creators. That works remarkably well in conjunction with FAQ.15, because 15 covers everything that is not open content, and so neatly dumps the responsibility for full compliance in the lap of each licensor in 16. And I particularly like the word "Yes", and the phrasing "Linden Lab also respects the wishes of creators who release their content under open source or open content licenses to make their content freely exportable." It would show good intentions directly, and without any fudging. Morgaine. == On Sat, Feb 27, 2010 at 4:32 PM, Fleep Tuque wrote: > (Sending for like the 4th time I hope this one gets through and sorry if > I've spammed) > > Regarding Morgaine's comments about FAQ 15 - I fully agree that this must > be the case: > > > On Sat, Feb 27, 2010 at 1:47 AM, Morgaine > wrote: > >> And finally, FAQ.15 (in the context of licenses permitting free >> distribution): >> >> >> >>- Q15: Do the limitations of section 2.b on content export apply to >>content that is full permissions? >>- A15: Yes, they do. Residents retain intellectual property rights in >>the content they create in Second Life and it is important for you to >>respect those rights. By setting content to "full permissions" using the >>Second Life permissions system, a content creator merely indicates that >> the >>content may be copied, modified, and transferred *within* Second Life. >> Setting content to "full permissions" does not provide any permission to >>use the content outside of Second Life. >> >> >> This is fine (surprise, surprise :P), but incomplete. It doesn't address >> the quite common scenario of full-perm content created by Open Source or >> Creative Commons developers *using 100% personal textures*, and >> accompanied by a GPL, BSD, CC or other open source license which declares >> that the content may be freely copied, modified, and transferred * >> anywhere*, not only within Second Life. >> >> As is written in the answer A15, "Residents retain intellectual property >> rights in the content they create in Second Life and *it is important for >> you to respect those rights*." Respecting their rights in this case >> requires you to to allow that content to be exported as its creator >> desires. Therefore you either need to extend A15 with this additional case, >> or add another FAQ Q+A (preferably immediately after #15) to address it. >> >> > > The free content I create for education is intended to be fully free, fully > permissioned, and fully exportable to other grids. Beyond the Second Life > permissions, I keep hoping for checkboxes on the Edit menu with common > licenses or a space to put a link to the user's specified license that is > kept with the object info just like creator name. > > In any case, when I include Creative Commons licensing with my educational > tools, and explicitly say users have my permission to explore the content to > other grids, then I expect that to be respected by Linden Lab as well! > > Sincerely, > > - Chris/Fleep > > > Chris M. Collins (SL: Fleep Tuque) > Project Manager, UC Second Life > Second Life Ambassador, Ohio Learning Network > UCit Instructional & Research Computing > University of Cincinnati > 406E Zimmer Hall > PO Box 210088 > Cincinnati, OH 45221-0088 > (513)556-3018 > chris.coll...@uc.edu > > UC Second Life: http://homepages.uc.edu/secondlife > OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php > > > ___ > 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] FAQ posted for Third Party Viewer Policy
You only covered textures there, Zha. Items made in Second Life are composite objects that encapsulate geometry, textures, notecards, and often scripting, and it is the whole composite unit that is being licensed as open content in the scenario being discussed here. What's more, it may include items that other open developers have released in SL under an open license as well, not only self-made components. (The suggested new FAQ.16 addresses this.) Clearly none of this is captured by putting textures on a website. What's more, putting the composite objects on a website cannot be done until after you export them, so it's a chicken and egg situation, and this is why a clause permitting open-licensed exports is required in the first place. Finally, your website idea reduces the opportunity for content sharing at which SL is so good. Open content creators should not be discouraged from building and learning with other people's open content by keeping it off-world on websites. Such content is already in-world in SL today (lots of it) under appropriate licenses. Note that I have carefully and explicitly placed the responsibility for compliance with FAQ.15 and with open licensing on the shoulders of the licensor. You mention that mechanisms to handle this do not exist within SL, but none are needed --- they don't exist in RL either, so it is handled in RL by enclosing a license. That works perfectly well here too, and it is already being done today. It needs to be covered in the TPV+FAQ. Morgaine. = On Sat, Feb 27, 2010 at 8:24 PM, Zha Ewry wrote: > Usual I am not a lawyer comments apply. > > One thing to keep in mind is that if you own the content, nothing requires > you to distribute it exclusively via Linden Lab's service. If you have a > set of textures which you hold rights to, putting them on Second Life > doesn't remove your rights to use and distribute those textures as you > see fit. > > While it would be nice if Second Life could distinguish between > free use within Second Life and Free use globally, at the moment > such mechanisms are absent. It's pretty straight forward to place > textures on standard web servers and make them available under the > appropriate license. I think the terms as written don't prohibit you from > downloading things you created, so again, it should be fine for you > to distribute them via other channels. > > > ~ Zha > > > > On Sat, Feb 27, 2010 at 3:02 PM, Morgaine > wrote: > > Fleep, you give an excellent example highlighting the needs of Education > in > > this area. > > > > Given the huge interest in educational content both in SL and in > > Opensim-based grids such as Science Sim, this is certain to be of major > and > > growing interest. > > > > Perhaps the FAQ could add a new clause FAQ.16 (renumbering the old FAQ.16 > > and all subsequent ones down) which reads something like this: > > > > Q16: Are the rights of open source or open content providers respected? > > A16: Yes. To further protect the rights of content creators beyond > FAQ.15, > > Linden Lab also respects the wishes of creators who release their content > > under open source or open content licenses to make their content freely > > exportable. (Typical licenses are GPL, BSD, or Creative Commons.) The > > responsibility for ensuring that such content does not contravene FAQ.15 > > rests entirely with the licensor, who must ensure that all parts either > > comply with FAQ.15 or have been released under an open license by their > > respective creators. > > > > That works remarkably well in conjunction with FAQ.15, because 15 covers > > everything that is not open content, and so neatly dumps the > responsibility > > for full compliance in the lap of each licensor in 16. > > > > And I particularly like the word "Yes", and the phrasing "Linden Lab also > > respects the wishes of creators who release their content under open > source > > or open content licenses to make their content freely exportable." It > would > > show good intentions directly, and without any fudging. > > > > > > > > Morgaine. > > > > > > > > > > > > == > > > > On Sat, Feb 27, 2010 at 4:32 PM, Fleep Tuque wrote: > >> > >> (Sending for like the 4th time I hope this one gets through and sorry if > >> I've spammed) > >> Regarding Morgaine's comments about FAQ 15 - I fully agree that this > must > >> be the case: > >> > >> On Sat, Feb 27, 2010 at 1:47 AM, > >> Morgaine wrote: > &
Re: [opensource-dev] FAQ posted for Third Party Viewer Policy
ay be copied, modified, and transferred within Second Life. Setting > content to "full permissions" does not provide any permission to use the > content outside of Second Life. > > This is fine (surprise, surprise :P), but incomplete. It doesn't address > the quite common scenario of full-perm content created by Open Source or > Creative Commons developers using 100% personal textures, and accompanied by > a GPL, BSD, CC or other open source license which declares that the content > may be freely copied, modified, and transferred anywhere, not only within > Second Life. > > As is written in the answer A15, "Residents retain intellectual property > rights in the content they create in Second Life and it is important for you > to respect those rights." Respecting their rights in this case requires you > to to allow that content to be exported as its creator desires. Therefore > you either need to extend A15 with this additional case, or add another FAQ > Q+A (preferably immediately after #15) to address it. That might be material for the FAQ. But because there is no export > permission bit, it's not possible to add export capability for these > cases without enabling violation of others' content. At this point, I > couldn't see that affecting the TPV policy. > An export permission bit is not required before export of open-licensed content can be done. We don't have an export permission bit in RL, and yet open licensing works just fine. As Fleep pointed out earlier<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000405.html>, SL creators are already open-licensing their products right now, since it is so important for Education. As in RL, the responsibility for applying open licenses properly rests with the licensor, since nobody else can be expected to check what the licensor is licensing. That is no different here. Nobody expects you to do any checking, and your assertion that this leads to "violation of others' content" is patently wrong when the licensor uses only her own and other people's open-licensed content. The core of the matter though is whether you believe in your own words in FAQ.15: "Residents retain intellectual property rights in the content they create in Second Life and it is important for you to respect those rights". Are you going to respect the rights of those creators who use open-licensing of their content? Or are you only going to respect the rights of those creators who shore up the walls of your walled garden? I would prefer to believe that your support is for all content creators' rights and wishes. How you respond will reveal the truth of the matter. If you make it clear that building upon the openly and legally-licensed content of others is a ToS or TPV violation, then you are not respecting the rights and wishes of open creators. My suggested new FAQ.16 or similar would let you "do the right thing" and be a good citizen of the open license community. Morgaine. === On Sun, Feb 28, 2010 at 1:31 AM, Soft Linden wrote: > On Sat, Feb 27, 2010 at 12:47 AM, Morgaine > wrote: > > > > Q2: Does the policy limit use of the viewer source code that Linden Lab > > makes available under the GPL? > > A2: No, the policy is not intended to and does not place any restriction > on > > modification or use of our viewer source code that we make available > under > > the GPL. Rather, the policy sets out requirements for connecting to our > > Second Life service using a third-party viewer, regardless of the viewer > > source code used. > > > > This looks great at first glance as it appears to make the separation > > between developers and users that caused so much confusion in TPV v1. > > > > But notice that the answer says "does not place any restriction on > > modification or use", and then goes on to say "Rather, the policy sets > out > > requirements for connecting". Well connecting IS use, it couldn't be > > anything else, so the answer contradicts itself in one and the same > > paragraph. Such ambiguities need to be removed. > > It's important to understand that one can discontinue use of Second > Life at any point. On doing so, there are no further obligations > imposed by the TPV policy. The legal consults cleared this as a > resolution to all free license issues. > > This agreement makes no restrictions on what anyone can do with the > source. The GPL makes no restrictions on connecting to Second Life. > These are two separate agreements, and don't need to be reconciled in > such a way that each permits everything allowed by the other. > > That said, Linden Lab inte
[opensource-dev] Mailman for opensource-dev on pipermail is slicing posts
For the month of February, there are now 4 posts (from different people) that have been sliced into pieces and their headers-less tail fragments placed into the mailing list archive with a Subject line of "No subject". See the top of the threaded view<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/thread.html>listing. Could someone please request the mail sysadmins to take a look at this bug? Cheers, 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] FAQ posted for Third Party Viewer Policy
You're talking commonsense, Thomas. Unfortunately, what's written down is not the commonsense interpretation that you are making of the words that are on paper. In a court of law, it is no defense to say "I was adhering to the commonsense interpretation provided by Thomas Shikami in the mailing list" (nor even quoting a Linden email). All that matters is what is written down in LL's official documents, and that is why we are taking great pains to get these words that Lindens are writing so sloppily into a suitable unambiguous form. They need to directly reflect what we all know is commonsense for user access to the SL service, and to be compliant with what is directly expressed in the GPLv2 license in respect of guaranteed developer freedoms. Our generous interpretations don't count here, only LL's official words do. And when making interpretations, you should always take the worst-case scenario, because that is what lawyers will use to hang you. Morgaine. === On Sun, Feb 28, 2010 at 6:44 PM, Thomas Shikami wrote: > Morgaine schrieb: > > GPLv2 clause 6 allows no "further restrictions" to be placed on the > > freedom of developers to /"modify and distribute/" whatsoever, > > regardless of whether the USAGE of that GPL software is constrained or > > not. The GPL has no interest is how software is used to connect to a > > service in the slightest. You can constrain USAGE of code for service > > access as much as you like, you can ban whomever or whatever you like, > > and it's completely immaterial to the GPL. The two things are > > entirely separate. The GPL is not a usage license. > > > > Long story short, if you want to be registered in the third party viewer > registry, you have to follow the TPV policies. The registration is > optional. If you don't register in the TPV, almost all rules that apply > to the developer have no meaning. If you want to use your viewer with > SL, you become a user of your viewer. Then the TOS and the TPV applies > to you as it restricts the usage of a user. > > Registering with the viewer registry is voluntary and LL doesn't impose > any "further restrictions" on you, because it isn't mandatory. Also you > can redistribute the registered viewer according to GPLv2 without > "further restrictions" on the receiver of that code. That party would > have to register a derivate of that viewer as well to be restricted by > the TPV as it applies on developer. > > If you don't use that viewer with SL, and you aren't registering the > viewer, then nothing of the TPV applies to 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 > ___ 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] FAQ posted for Third Party Viewer Policy
On Mon, Mar 1, 2010 at 12:27 AM, Joe Linden wrote: > Yes, Mike, we created the Third Party Viewer Directory to promote a range > of viewers that allow Residents to experience Second Life and everything in > it in a wide variety of ways. Joe, thanks for clarifying that what you are doing with the Directory is "promotion" of Third Party Viewers. Since it's just promotion, TPV developers are free to ignore it when they excel on features and don't need promotion, and of course you will never make promotion mandatory. It's great that you clarified this, because people were mistakenly thinking that instead of promotion, what you were trying to do is to regulate 3rd party viewers and prevent them from gaining features that push the envelope and make your own viewers look poor in comparison. It's always useful when such misapprehensions are laid to rest. Have a good day, and many thanks! :-) Morgaine. On Mon, Mar 1, 2010 at 12:27 AM, Joe Linden wrote: > Yes, Mike, we created the Third Party Viewer Directory to promote a range > of viewers that allow Residents to experience Second Life and everything in > it in a wide variety of ways. Since we'll be pointing to it often, it's a > great way for the largest possible audience of Residents to learn about > viewer alternatives that have been submitted by developers willing to > certify that the viewer complies with the policy for all 3rd party viewers > that connect to SL. > > And we haven't release Viewer 2.0 yet. It's in open beta now to take > constructive feedback from (new and longtime) Residents. If it also > stimulates great alternative viewers that comply with the policy, then we've > accomplished several of our goals. > > -- joe > > > > On Sun, Feb 28, 2010 at 3:58 PM, Mike Monkowski > wrote: > >> So you've created this Third Party Viewer Directory in order to >> *promote* third part viewers? *That's* your "why"? Well, you needn't >> have bothered. You did much more to promote third party viewers by >> releasing Viewer 2.0. >> >> Mike >> >> Soft Linden wrote: >> > I feel I should add too - this isn't all stick, as my below >> > speculation about legal's intent might have suggested. Remember that >> > we're creating the Viewer Directory to promote other viewer projects, >> > so complying with the TPV terms offers up a pretty good carrot. >> > However, I think legal also knows we'd be making trouble for ourselves >> > if we gave even the whiff of an endorsement to a tool that hurt our >> > resis or the Lab. So, legal needed to offer some objective rules >> > before we could promote any projects. >> > >> > I hope this is helping. I worried that one of the most frustrating >> > parts of the TPV might be that it was landing with a big "what" >> > without enough "why" behind it. Most people react pretty badly to >> > anything that looks like control for control's own sake. >> ___ >> 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 > ___ 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] FAQ posted for Third Party Viewer Policy
Byron, your personal interpretation is at odds with Joe's words. Plus, Joe has just confirmed what he said earlier regarding "promotion" anyway, and it's exactly as he wrote the 1st time around, so it's your understanding that is flawed. Having your viewer listed in the TPV Directory is a developer's *choice*. Read Joe's words: On Mon, Mar 1, 2010 at 1:36 AM, Joe Linden wrote: > TPV developers may *choose* to list their viewers in the Directory for the > value of receiving a wider awareness than they may be able to create > themselves, or not. *That's entirely up to the developer.* All *viewers > that connect* to the SL grids will need to *abide* by the TPV Policy > regardless of their choice to list in the Directory. > > And, since we're only talking about conditions that apply when a TPV > connects to Linden Lab's grid(s), we reserve the right to add, subtract, or > otherwise modify those conditions at any point in the future. Unlike the language in the TPV and in most of the FAQ, Joe's words here are crystal clear, unambiguous, and make perfect sense. The choice of listing is a developer's choice, and Joe confirms that it's for "receiving a wider awareness than they may be able to create themselves, or not" --- ie. optional *promotion*, for the developer's benefit, and genuinely not mandatory. There is not a hint of coercion against developer's freedom to modify and distribute in Joe's words. [And hurrah for that, because that's one less hurdle towards compliance with GPLv2 clause 6.] And then, separately, Joe points out that it is *viewers* (not developers) which connect to SL that need to comply with LL's policy requirements when connected, which makes perfect sense. Joe underlines that point even more strongly: "*we're only talking about conditions that apply when a TPV connects to Linden Lab's grid(s)*". That's an extremely strong disclaimer --- LL has no interest in what developers do, nor in what viewers outside of SL do, but only in what viewers do when they are connected to SL. It's totally sensible. And your interpretation, Byron, bears no relation to it whatsoever. Morgaine. == On Mon, Mar 1, 2010 at 1:30 AM, Bryon Ruxton wrote: > Morgaine, I think your statement is a misunderstanding on your part. It’s > not “just promotion”. > > You don’t have a choice but to be be listed AND comply if you want to > legitimately connect to the grid with your viewer. As originally intended by > LL. They are not exclusive as currently implemented and described, unless > they change that: “agree to our Policy on Third-Party Viewers and the Second > Life Terms of Service. If you do not agree, you are ineligible for the > Viewer Directory, and you do not have permission to access Second Life using > a third-party viewer.“ > > i.e. You either comply AND feature in the "viewer registry". OR ignore it, > as you said and you’d be in breach of the TOS as such: “5.6 You will > indemnify Linden lab from claims arising from breach of this Agreement by > you, from your use of Second Life, from loss of Content due to your actions, > or from alleged infringement by you”. > > And I don’t think opting out of the "viewer registry" should or ever will > be an option. > > > On 2/28/10 4:44 PM, "Morgaine" wrote: > > Joe, thanks for clarifying that what you are doing with the Directory is > "promotion" of Third Party Viewers. Since it's just promotion, TPV > developers are free to ignore it when they excel on features and don't need > promotion, and of course you will never make promotion mandatory. > > ___ 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] FAQ posted for Third Party Viewer Policy
On Mon, Mar 1, 2010 at 2:02 AM, Tateru Nino wrote: > Ah, I'm starting to see now. Developers are only subject to the TPV policy > if they want to be listed in the directory. Users are subject to the policy > should they choose to use a TPV to connect to a Linden-operated grid, rather > than an alternative (like OpenSim) > > It's getting better, isn't it, logic is finally creeping in. :-) Joe's two posts above are the first to cleanly separate developers, viewers and users connecting to SL, and to discuss each one separately in their individual spheres without conflating them. If Joe were to write the whole TPV, we could probably all go home early. ;-) > Makes sense, but that would really mean that the TPV policies should be a > part of the Terms of Service, wouldn't it> Doesn't make much sense to have > them separated. > > Yes, you're right. Since the only thing that is regulated is the behavior of viewers within SL, it's all about Terms of Service. Indeed, a document imposing restrictions on something outside of LL's service makes no sense at all anyway, as well as wreaking havoc with GPLv2's clause 6. Joe has unpicked what was previously a bundle of spaghetti and made it comprehensible. [Kudos for that!] We're not home yet though. Apparently the wishes and rights of open-license content creators are going to be ignored and dismissed. This is unnecessary, unconscionable, and quite possibly illegal. And it's simply not right either. Before planting the mast at that spot, I suggest a little extra thought, because this is very bad on multiple fronts, and any gains that LL thinks it might make from it will probably be less than the damage. And the cost of doing The Right Thing is almost nil, because these legal rights are being exercised already, and all that's missing is a corresponding clause in TPV and FAQ. Morgaine. On Mon, Mar 1, 2010 at 2:02 AM, Tateru Nino wrote: > Ah, I'm starting to see now. Developers are only subject to the TPV policy > if they want to be listed in the directory. Users are subject to the policy > should they choose to use a TPV to connect to a Linden-operated grid, rather > than an alternative (like OpenSim) > > Makes sense, but that would really mean that the TPV policies should be a > part of the Terms of Service, wouldn't it> Doesn't make much sense to have > them separated. > > > On 1/03/2010 12:36 PM, Joe Linden wrote: > > TPV developers may choose to list their viewers in the Directory for the > value of receiving a wider awareness than they may be able to create > themselves, or not. That's entirely up to the developer. All viewers that > connect to the SL grids will need to abide by the TPV Policy regardless of > their choice to list in the Directory. > > And, since we're only talking about conditions that apply when a TPV > connects to Linden Lab's grid(s), we reserve the right to add, subtract, or > otherwise modify those conditions at any point in the future. > > -- joe > > On Sun, Feb 28, 2010 at 4:44 PM, Morgaine > wrote: > >> >> ... Since it's just promotion, TPV developers are free to ignore it when >> they excel on features and don't need promotion, and of course you will >> never make promotion mandatory. >> >> 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 > > > -- > Tateru Ninohttp://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] FAQ posted for Third Party Viewer Policy
Reposting part of last response to Soft, which the list's Mailman/pipermail sliced off. >> As is written in the answer A15, "Residents retain intellectual property >> rights in the content they create in Second Life and it is important for you >> to respect those rights." Respecting their rights in this case requires you >> to to allow that content to be exported as its creator desires. Therefore >> you either need to extend A15 with this additional case, or add another FAQ >> Q+A (preferably immediately after #15) to address it. >> > > That might be material for the FAQ. But because there is no export > > permission bit, it's not possible to add export capability for these > > cases without enabling violation of others' content. At this point, I > > couldn't see that affecting the TPV policy. > An export permission bit is not required before export of open-licensed content can be done. We don't have an export permission bit in RL, and yet open licensing works just fine. As Fleep pointed out earlier<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000405.html>, SL creators are already open-licensing their products right now, since it is so important for Education. As in RL, the responsibility for applying open licenses properly rests with the licensor, since nobody else can be expected to check what the licensor is licensing. That is no different here. Nobody expects you to do any checking, and your assertion that this leads to "violation of others' content" is patently wrong when the licensor uses only her own and other people's open-licensed content. Indeed, if you did do checking then you would not be able to disclaim liability for infringements. The core of the matter though is whether you believe in your own words in FAQ.15: "Residents retain intellectual property rights in the content they create in Second Life and it is important for you to respect those rights". Are you going to respect the rights of those creators who use open-licensing of their content? Or, ungenerously, are you only going to respect the rights of those creators who shore up the walls of your walled garden? I would prefer to believe that your support is for all content creators' rights and wishes. How you respond will reveal the truth of the matter. If you make it clear that building upon the openly and legally-licensed content of others is a ToS or TPV violation, then you are not respecting the rights and wishes of open creators, and it may not even be legal. My suggested new FAQ.16 or similar would let you "do the right thing" and be a good citizen of the open license community. 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] Fwd: FAQ posted for Third Party Viewer Policy
Back in the old days of Philip's SL, Lindens often proclaimed the futility of entering an arms race, and the channel concept stems from that --- self-identification as a choice, in the knowledge that stronger measures will always be countered anyway. It seems that those days are long gone though. Anyone wanting a solid business for the next few years might consider selling brooms to SL protectionists. There's a lot of tide to sweep back. ;-) Morgaine. === On Mon, Mar 1, 2010 at 4:05 AM, Maggie Leber (sl: Maggie Darwin) < mag...@matrisync.com> wrote: > -- Forwarded message -- > From: Maggie Leber (sl: Maggie Darwin) > Date: Sun, Feb 28, 2010 at 11:04 PM > Subject: Re: [opensource-dev] FAQ posted for Third Party Viewer Policy > To: Tigro Spottystripes > > > On Sun, Feb 28, 2010 at 10:59 PM, Tigro Spottystripes > wrote: > > An user agent string for the client would indeed be useful, but would be > > useless to catch all but the lamest malicious clients. > > Well, I though that's what the required "unique channel" is for. > ___ > 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] FAQ posted for Third Party Viewer Policy
On Mon, Mar 1, 2010 at 2:10 PM, Argent Stonecutter wrote: > Then make the policy state that. Right now people are seeing it as > ambiguous. +1 Argent. Joe has provided very clear and totally unambiguous phrasings, LL please use them. While lawyers may thrive on pocket-lining ambiguity which empowers them to shift the goal posts at will when applying the rules or in court, it is not in the interest of the community for the wording of ToS, TPV or FAQ to be ambiguous. Get rid of the previous mess on this issue and use Joe's formulation, please. It vastly simplifies GPL compliance when the statements concerning developers, users, and viewers connecting to SL are entirely separate. It then becomes very easy to identify that there are no "further restrictions" on the developer's GPL-guaranteed *freedoms to modify and distribute* GPL software. Restrictions that apply to viewers when they connect to SL, or restrictions that apply to users of SL, are of no interest to the GPL at all, so making sure that developers do not appear in any statement concerning restrictions is the key to GPL compliance. It's really easy to be GPL compliant. Joe's post here is entirely compliant with GPLv2 clause 6, purely because of that clean separation. This same approach of keeping the three targets of restrictions separate needs to be used also when the other areas of GPL non-compliance are addressed. It will then be easy to make rapid progress. It's worth highlighting the importance of the phrase "viewers when they connect to SL", or "we're only talking about conditions that apply when a TPV connects to Linden Lab's grid(s)" as Joe wrote. This is crucial. It means that LL's restrictions do not apply to the same viewer being used on an independent grid for example. Joe's clear qualification of "viewer" with "connecting to SL" is a community-friendly form of wording that clearly limits the scope of restrictions to SL alone, and it isolates "modify and distribute" from "use" perfectly for GPL purposes. Morgaine. === On Mon, Mar 1, 2010 at 2:10 PM, Argent Stonecutter wrote: > > On 2010-02-28, at 19:36, Joe Linden wrote: > > TPV developers may choose to list their viewers in the Directory for the >> value of receiving a wider awareness than they may be able to create >> themselves, or not. That's entirely up to the developer. All viewers that >> connect to the SL grids will need to abide by the TPV Policy regardless of >> their choice to list in the Directory. >> >> And, since we're only talking about conditions that apply when a TPV >> connects to Linden Lab's grid(s), we reserve the right to add, subtract, or >> otherwise modify those conditions at any point in the future. >> > > Then make the policy state that. Right now people are seeing it as > ambiguous. > ___ 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] Snowglobe as an mixed reality platform
Merov, further to Kantonen+Suzy and Lawson's posts about Snowglob extensions, once the 2.0 code merges settle down, can we please get back to the topic of client-side scripting that was rudely interrupted by the TPV debacle? It is precisely that kind of generic scriptable extension mechanism that will allow easy integration into Snowglobe of industry-sponsored projects such as that of VTT+IBM and well as community projects such as Saijanai's work with Cobalt, instead of requiring each new application to be grafted on as special cases. Every special external plugin will need to communicate with an effective API in the viewer, and expanding the viewer API for each such external plugin is clearly not scalable nor even viable, not to mention inflexible. This is why a generic viewer API for communicating with pluggable extensions is extremely important for the future of Snowglobe as an extensible application. The number of possible extensions is unbounded, but the hundreds of eyes focussed on this mailing list are probably sufficient to come up with a suitably generic API and a good infrastructure design for managing these kinds of extensions. Morgaine. On Tue, Mar 2, 2010 at 10:48 PM, Lawson English wrote: > I'm working on mixing Cobalt with SL via the media plugin. Here's a bit > of discussion of how it (and future plugins) might work: > > http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion > > Lawson > > Suzy Deffeyes wrote: > > I'm very interested in this work ( full disclosure, IBM is one of the > > sponsors of the work), Moriz, I agree that today's head mounted > > displays are a bit bulky for widespread use. It is great foundational > > work, and there are some aspects that we could integrate into > > Snowglobe that would be useful *today*. One of those is the gesture > > recognition code. It's towards the end of Tuomas' video. It uses a > > webcam to detect a user nodding yes/no, and then plays an in world > > animation based on detecting the gesture. > > > > Merov, once the Snowglobe 2.0 code settles down, can we discuss a way > > to have a pluggable framework that people could use for things like > > AR? Might make a good topic for a Hippo meeting. > > Suzy > > > > On Tue, Mar 2, 2010 at 9:10 AM, Moriz Gupte > <mailto:moriz.gu...@gmail.com>> wrote: > > > > This is very neat. Still a bit bulky for immediate use but a great > > foundation for future. > > R > > > > > > On Tue, Mar 2, 2010 at 3:31 AM, Kantonen Tuomas > > mailto:tuomas.kanto...@vtt.fi>> wrote: > > > > Hello, > > > > I've been working on a project using Second Life as a platform to > > develop mixed reality teleconferencing/-collaboration system. > > A brief > > intro about the project can be found at > > http://www.vtt.fi/multimedia/projects/mrconference.html > > and a video demo of our work so far is at > > http://www.youtube.com/watch?v=DNB0_c-5TSk . > > > > The project, continuing also in 2010, is split into two parts: > > overlaying a video image with avatars and virtual objects > > (augmented > > reality; AR) and using hand and head gestures to control > > avatars and > > interact with virtual objects (augmented virtuality; AV). > > > > We have agreed to release our work as open source. However, > > lack of > > continuous "forward porting" would soon render the released code > > unusable. It would therefore be better to have some parts of our > > work incorporated into the Snowglobe sources. > > > > I've tried to keep all our modifications as small as possible. > The > > project is separated to our own ACME (Augmented Collaboration > > in Mixed > > Environments) module, vanilla Snowglobe code and an interface > > between > > the two. > > > > I'd be ready to invest some time to implement a generic AR/AV > > support > > for Snowglobe if we could come up with a design that could be > > accepted > > by the Snowglobe developers. This would allow anyone to use > > Snowglobe > > as AR/AV research platform, with or without our software. > > > > ___ > 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] TPV & opensim & physics prediction
That's a great idea, Tigro! I think I'll bring it up in the context of realXtend's Naali + Opensim some time. They might well be interested in accelerating static content, and since Naali is evolving so rapidly and is highly modular, it might not be terribly hard to do. PS. The AW Groupies meeting we had with realXtend this morning was excellent and very well attended, sparking a ton of interest in Naali. (See Sai's earlier post<https://lists.secondlife.com/pipermail/opensource-dev/2010-March/000531.html>for link to transcript.) Morgaine. === On Wed, Mar 3, 2010 at 2:00 AM, Tigro Spottystripes < tigrospottystri...@gmail.com> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > i'll take the opportunity to promote a somewhat related feature > suggestions i've posted on pjira: > http://jira.secondlife.com/browse/VWR-13942 - Optimize non-dynamic > content on sims > > > On 2/3/2010 22:05, Argent Stonecutter wrote: > > On 2010-03-02, at 18:49, Dzonatas Sol wrote: > >> Let's add "burning man" event... so that is how many more sims! > > > > When I had a build in Burning Life, I was updating it all the way > > through the show, and I saw several people around me doing the same. > > > > That's just how SL gets used, in practice. If you want static builds > > that get uploaded and frozen into the sim, that's what Blue Mars is > > all about. > > ___ > > 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 > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.12 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkuNwtcACgkQ8ZFfSrFHsmXMpACdEX036IjCLQ0r88cm6TV/UIuQ > jbUAnRA+7vnwGV5teRp8r92L88aZuFYw > =MBSt > -END PGP SIGNATURE- > ___ > 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] Eclipse Guru's
Jonathan, we'll have all that and more, as soon as we have client-side scripting. It truly is the universal panacea, because it will allow simple tools to be scripted directly, and complex tools to be linked in via the script as an interface, and orchestrated to work with the viewer. I think perhaps not everybody realizes the immense power of client-side scripting and the totally overriding effect it will have on every aspect of the viewer and on people's interaction with virtual worlds. Nothing else comes close to being as important and as game changing. And this is why it needs to be discussed and designed here openly in opensource-dev, not in secret by Lindens. It is not only Lindens and LL who are affected by this. We all are, and we all need to be involved, because it is our future. Merov, once your 2.0 merges have stabilized, this needs to be on the front burner. If it's not, then it will be done in 3rd party clients and Snowglobe will become irrelevant, to the detriment of nobody but yourselves because you will lose what little control you have over the future. Morgaine. == On Wed, Mar 3, 2010 at 3:03 PM, Jonathan Irvin wrote: > I do often hear complaints and wishes for new build tools, what about us > LSL devs? Some things I would like are: > >1. Better IDE in SL Viewer >2. API for compiling in LSL using various IDEs already available >3. Going along with #1, as suggested, integrating Eclipse or equivalent >in SL. >4. LSL Wiki built into the editor >5. Detachable script editing window (To develop on one monitor & test >in the other) >6. Entity relationship diagram system in SL viewer for visual coding. > > > ___ > 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] Eclipse Guru's
Ambroff, adding a specialized interface just to support an IDE is a very bad idea. It's a completely non-scalable approach, very inflexible, and it is simply too much work to add bespoke code each time a new application is wanted. And worst of all, it doesn't allow the user community to add their own applications freely, since it requires internal viewer changes each time. This is why we were discussing generic client-side scripting here last month, both for viewer extensions and for world enhancement<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000173.html>. There is quite of lot of history in this area among viewer developers already, as various groups have been examining the issue. In AWG we looked at the general area of refactoring viewer functionality in the Multi-Process Client<https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft>concept, way back, which split everything into communicating plugins. Two or three 3rd party viewer teams (notably Emerald) experimented with an embedded Lua console, so they have some experience with language VM interfacing to a viewer API. And in Imprudence, we spent some months designing a language-agnostic plugin system<http://imprudenceviewer.org/w/images/4/48/Plugin_system_flow_APIs.png>that allows plugins to be written in any language that supports sockets, using JSON as the lingua franca for communicating with viewer API functions and callbacks -- see the threads labeled "[Plugins]" in the Imprudence Forums <http://imprudenceviewer.org/forums/viewforum.php?f=7> for more details. We even tested the limiting bandwidth and latency for such a plugin system just to be sure that we were on solid ground. This is the kind of infrastructure that would support IDE applications with great ease, without requiring internal viewer modification for each new type of external application. Once the basic plugin communications engine is in place, all that is needed is to expose everything of interest in the viewer as a Viewer API, and map incoming message names to API functions. Various people have also suggested that a hierarchical dataspace equivalent to a browser DOM could be defined in the viewer, so that viewer data can be accessed by scripts in a clean symmetrical fashion, which makes a lot of sense. There is an internal Linden project (Firefly) looking at client-side scripting as well, but that is being designed behind closed doors to fulfill some unknown internal Linden requirement. That's fine for the official Linden viewer of course, but it is not sufficient for the community viewer that is Snowglobe. Here we need a lot more, which last month's thread started to enumerate. We also need an open design process, because there are a lot of clever people on this list with insights on how best to tackle it, and a lot of different requirements will need to be met. And just on principle, design secrecy has no place in an open source community viewer project anyway. Morgaine. = On Thu, Mar 4, 2010 at 8:28 PM, Ambroff Linden wrote: > On Wed, Mar 3, 2010 at 7:03 AM, Jonathan Irvin wrote: > >> I do often hear complaints and wishes for new build tools, what about us >> LSL devs? Some things I would like are: >> >>1. Better IDE in SL Viewer >>2. API for compiling in LSL using various IDEs already available >>3. Going along with #1, as suggested, integrating Eclipse or >>equivalent in SL. >>4. LSL Wiki built into the editor >>5. Detachable script editing window (To develop on one monitor & test >>in the other) >>6. Entity relationship diagram system in SL viewer for visual coding. >> >> I'm not sure that spending whole lot of time adding fancy features to the > built in LSL editor is that productive (we aren't trying to build an IDE, > and there are a ton of really good extensible IDEs out there already), but I > really like your idea of putting together an API. Someone could hack a > service into the viewer that lets another process (like Eclipse or > Monodevelop) perform limited operations on the inventory of the currently > selected object. > > We already have D-Bus <http://www.freedesktop.org/wiki/Software/dbus> > integration > in the GNU/Linux Viewer for SLurl support, so it shouldn't be too hard to > expose something like an ObjectEditorProxy. It could allow an extension for > your favorite IDE to enumerate the scripts that are editable in the > currently selected object's inventory, fetch their contents, compile(), and > add new scripts to the object's inventory. The IDE could also subscribe to > events emitted by the viewer, such as ScriptAdded, ScriptDeleted, etc. > > What might improve the situation quite a bit is if th
Re: [opensource-dev] Eclipse Guru's
Sai, that's exactly how we we were designing Imprudence's plugin system. JSON messages sent by a plugin script were decoded on arrival in the viewer's socket plugin interface, and dispatched to invoke corresponding functions in the Viewer API. Some API functions set up callbacks, typically when registering interest in data expected to arrive in the future, ie. subscribing to an event. For example, a script might register interest in receiving incoming IM chat for a particular group. This would set up an appropriate callback, and then whenever chat arrives for this group the callback would be invoked to send the chat to the plugin as payload in an appropriate message. Any number of plugins could make such registrations to the same event --- for example one plugin might feed an external graphic chat window, while another could feed a text-to-speech synthesizer without requiring any visual representation. In general, every event of potential interest in the viewer should be made available at the Viewer API so that scripts can subscribe to it if wanted. Fortunately this is not a huge task because most events share much in common with each other, so it's mainly a job of enumeration and assigning appropriate payload types. Morgaine. == On Fri, Mar 5, 2010 at 12:35 AM, Lawson English wrote: > Ambroff Linden wrote: > > On Wed, Mar 3, 2010 at 7:03 AM, Jonathan Irvin > <mailto:djfoxys...@gmail.com>> wrote: > > > > I do often hear complaints and wishes for new build tools, what > > about us LSL devs? Some things I would like are: > > > >1. Better IDE in SL Viewer > >2. API for compiling in LSL using various IDEs already available > >3. Going along with #1, as suggested, integrating Eclipse or > > equivalent in SL. > >4. LSL Wiki built into the editor > >5. Detachable script editing window (To develop on one monitor > > & test in the other) > >6. Entity relationship diagram system in SL viewer for visual > > coding. > > > > I'm not sure that spending whole lot of time adding fancy features to > > the built in LSL editor is that productive (we aren't trying to build > > an IDE, and there are a ton of really good extensible IDEs out there > > already), but I really like your idea of putting together an API. > > Someone could hack a service into the viewer that lets another process > > (like Eclipse or Monodevelop) perform limited operations on the > > inventory of the currently selected object. > > > > We already have D-Bus > > <http://www.freedesktop.org/wiki/Software/dbus> integration in the > > GNU/Linux Viewer for SLurl support, so it shouldn't be too hard to > > expose something like an ObjectEditorProxy. It could allow an > > extension for your favorite IDE to enumerate the scripts that are > > editable in the currently selected object's inventory, fetch their > > contents, compile(), and add new scripts to the object's inventory. > > The IDE could also subscribe to events emitted by the viewer, such as > > ScriptAdded, ScriptDeleted, etc. > > > > What might improve the situation quite a bit is if the server > > supported a capability that allowed the viewer to fetch all symbols > > exported by the simulator (all LSL functions and constants). That > > metadata could then be exposed to the IDE through the > > ObjectEditorProxy for intellisense support. > > > > In the long run I don't know if this is a good solution, but it would > > certainly be an interesting experiment! > > > > -Ambroff > > I like the idea of a subscription to events. > > What we need is a way to register a handler/subscriber for ANY(more or > less) arbitrary event, the data of which can be shared via the same > mechanisms as the media plugin: socket and/or shared memory. > > For security's sake, we then need a way for the user to checkbox which > events are allowed to be handled by which plugin. The default setting > for all events for all plugins wold be NOT ALLOWED. > > If we standardize the interface and plugin protocols the right way, > non-Linden viewers can also use these plugins and the viewer > architecture can be changed without breaking an existing plugin > (assuming that a specific plugin makes sense at all with some future > architecture, of course). > > This same system could be used by an internal scripting system ala what > Q has talked about with mono/C# (just bypass the socket/sharedmemory i/o > for a handler implemented in the internal scripting language) and by > external scripting systems
Re: [opensource-dev] SNOW-553: C++ API needed to write the IPC part needed for plugins (like client-side scripting, augmented reality, LSL IDE, etc etc)
Good idea, Aleric. I added a long comment on the Jira to fill in some of the background details so that the C++ part of the plugin engine can be discussed in context. There are lots of possible approaches to this. I think it'll be interesting to knock them around. I hope we get some buy-in. Morgaine. On Fri, Mar 5, 2010 at 12:54 PM, Aleric Inglewood < aleric.inglew...@gmail.com> wrote: > I created https://jira.secondlife.com/browse/SNOW-553 for discussion (see > topic). > > Aleric > > > ___ > 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] Snowglobe as an mixed reality platform
On Sat, Mar 6, 2010 at 1:36 AM, Philippe (Merov) Bossut wrote: > > At the same time, I don't think it's reasonable to wait for the Glorious > Future to show up before considering contributions and experimentations like > yours (or we'll never get anywhere...). > > OK, let's start somewhere then. If you already do have code ported to > Snowglobe, it's worth setting up a place to post this so we can review and > see how best we could integrate that in the current architecture. I > encourage you to create a JIRA on the public JIRA and attach a patch to it > (I'm expecting a big patch though...). Considering the breath of the > feature, you should also create a page on the wiki to store there any > documentation. Let me know if you need help for this, I'll be happy to > assist you. > > Merov, are you giving IBM and IBM-sponsored projects an inside track in Snowglobe? The IBM-developed OGP code went into Snowglobe with barely any question, despite being tightly entangled with the legacy networking instead of a clean separate protocol module. And now you seem to be embracing with open arms an almost unknown third party development sponsored by IBM. Does the rest of the opensource-dev community get similar treatment and encouragement to add large areas of new functionality into Snowglobe? We've been trying to gain your interest and attention in client-side scripting because that is so massively more important and empowering in an open community viewer, yet you have seen fit to dismiss it, indeed not even to engage in the topic. If Snowglobe is a 2-party playpen for LL and IBM in respect of adding major functionality, while other open source developers only get to fix your bugs and tinker at the edges, then please say so. Alternatively, please pay attention to what the rest of this list wishes for Snowglobe as well. Morgaine. = On Sat, Mar 6, 2010 at 1:36 AM, Philippe (Merov) Bossut wrote: > Hi Tuomas, > > First, thanks a lot for joining us here in Snowglobe. I've seen your video > when it came out a few months ago and I was hoping to see you chime in here > back then :) > > On Tue, Mar 2, 2010 at 2:31 AM, Kantonen Tuomas wrote: > >> The project, continuing also in 2010, is split into two parts: >> overlaying a video image with avatars and virtual objects (augmented >> reality; AR) and using hand and head gestures to control avatars and >> interact with virtual objects (augmented virtuality; AV). >> >> We have agreed to release our work as open source. However, lack of >> continuous "forward porting" would soon render the released code >> unusable. It would therefore be better to have some parts of our >> work incorporated into the Snowglobe sources. >> > > The whole thing is: which parts? As others mentioned in this thread, we > eventually would like to develop a plugin architecture that will make easier > for this kind of work to be developed and integrated. We do have such an > embryonic API used for media currently. I think we could expand that > architecture to integrate things like avatar gesture and puppeteering as you > did (something I also do have some experience with and a personal interest > in). > > At the same time, I don't think it's reasonable to wait for the Glorious > Future to show up before considering contributions and experimentations like > yours (or we'll never get anywhere...). > > >> >> I've tried to keep all our modifications as small as possible. The >> project is separated to our own ACME (Augmented Collaboration in Mixed >> Environments) module, vanilla Snowglobe code and an interface between >> the two. >> > >> I'd be ready to invest some time to implement a generic AR/AV support >> for Snowglobe if we could come up with a design that could be accepted >> by the Snowglobe developers. This would allow anyone to use Snowglobe >> as AR/AV research platform, with or without our software. >> > > OK, let's start somewhere then. If you already do have code ported to > Snowglobe, it's worth setting up a place to post this so we can review and > see how best we could integrate that in the current architecture. I > encourage you to create a JIRA on the public JIRA and attach a patch to it > (I'm expecting a big patch though...). Considering the breath of the > feature, you should also create a page on the wiki to store there any > documentation. Let me know if you need help for this, I'll be happy to > assist you. > > Cheers, > - Merov > > > > ___ > 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 Permissions Management
The whole approach to objects and assets needs to change anyway, because of interop. Interop is a process --- it doesn't appear suddenly out of nowhere, you have to pave the way by evolving your code into a more flexible form. There is an implicit assumption in the viewer that everything is stored in one world's own repository, and that this world also holds all ownership and permissions data. This is changing as more grids and independent asset services appear, leading to a mashup scenario in which a region will contain elements which are held authoritatively in a variety of places elsewhere. As you are developing your own viewer, I suggest that you revamp your object and asset data and metadata handling to include querying external services, because that is where everyone is heading. VWRAP is moving in that direction by decoupling all services, realXtend's Naali already features external WebDAV-based inventories, Opensim has long had Hypergrid which reflects asset requests back to a traveller's home region, and the new Connector system in Opensim offers huge scope for non-centralized object and asset authority. The days of centralized objects and assets are coming to an end, and new viewer code needs to take that into account. Morgaine. = On Sat, Mar 6, 2010 at 12:52 AM, Rob Nelson wrote: > While working on my viewer's object handling stuff, I happened across a > rather fundamental flaw in the SL viewer's architecture. > > When one considers filesystem permissions or even database permissions, > you notice that permissions are generally attached to the object that a > user attempts to access, or the permissions are obtainable from a > central source that has a simple way to grab the permissions. > > >From my casual glance at the viewer code, I noticed that the latter is > the case in the LL viewer. However, there's a rather large problem for > those of us who are writing client-side scripting APIs. > > Consider a user in a sandbox who wants to clean up his mess. If he were > using a viewer based on LibOMV, all the viewer would have to do is loop > through the region's object dictionary and return/delete objects that he > owns. In the LL viewer (correct me if I'm wrong), LLSelectMgr actually > returns the permissions (*and owner/creator info*) , so the viewer would > have to select each and every object within the sim to grab its > permissions, which seems rather wasteful of bandwidth, and troublesome > in general. This works fine for situations where the object is selected > anyway (when building or right-clicking), but it's horribly inefficient > for scripting. > > I haven't dug deep enough yet to fully grasp what is going on in > LLSelectMgr, but it seems to me that it would be a lot more efficient to > simply attach the permissions with each object's properties when they > are sent to the client by the server, eliminating the need for scripts > (and bots) to have to spam the server requesting permissions. > > Fred Rookstown > Luna Viewer > > ___ > 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] Script Memory Limits UI
You have to be joking. (Or rather, Kelly has to be joking.) It's been decades since computer users last had to specify the memory requirements of their programs in advance of running them. Has 1970 returned again? This is progress? Morgaine. On Sat, Mar 6, 2010 at 4:39 PM, Garmin Kawaguichi < garmin.kawagui...@magalaxie.com> wrote: > Oh! And read the Kelly's comments in > https://blogs.secondlife.com/community/technology/blog/2010/03/05/server-138-beta-now-open > : > > "Right now there is no way to change how much memory a mono script uses, > and it is true that at any given point it probably uses less than 64k, by > some amount. However, before we enforce script limits, which again is still > a ways off, we will enable the ability to set a lower max memory size for > mono scripts. If your script really only uses 4k, congrats you can set it > to that and it will only count as 4k, and you won't be able to use more > until you change it. *This will be implemented before we enforce limits* > ." > > GCI > > > - Original Message - > From: "Matt White" > To: > Sent: Saturday, March 06, 2010 5:21 PM > Subject: [opensource-dev] Script Memory Limits UI > > 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 > ___ 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] Script Memory Limits UI
I agree completely, Marine. We're being given a choice of two options which together make no sense, and worse, represent an undue burden on scripters and a regression into the distant history of Computing. The system should define a *large* but *hard* limit to the maximum memory allocated per script, while at runtime, each script should automatically be allocated only as much as it needs to run, without needing to request any specific allocation. Any other strategy is both a waste of memory and a burden on developers (most of whom are not experts), as well as a return to antique manual allocation which is best left to the mists of history. Morgaine. == On Sun, Mar 7, 2010 at 11:20 AM, Marine Kelley wrote: > Well we have two mutually exclusive solutions here. > > Either Mono scripts are given a hard memory limit that we (the scripters) > can change within the scripts, with all the overhead work that it implies > (i.e. modifying hundreds of scripts before issuing an update, and having to > know upfront how much memory will be taken exactly), which means that in > regards to the scripts memory usage UI, the script will use exactly as much > as the limit it has requested, no matter whether it really uses it or not. > This gives wasted memory and false information. > > Or, Mono scripts are given a hard memory limit that we cannot change, and > they report exactly as many bytes as they use at any time. But we shouldn't > be able to change the limit ourselves, because it wouldn't make sense to do > so, it would only be restraining ourselves if we set less than 64k, and > wasting memory space if we set more than 64k. > > In both cases, the question of whether the script crashes when reaching the > limit or not is not related. > > I seriously, and I mean seriously, think that choosing the first option is > going to hurt the established scripters very badly, and therefore the grid > as a whole. To me scripts should report exactly as much memory as they use, > not more, and should not require the scripters to modify them to report > something that could be computed by the sims more accurately anyway. > > Of course it is tempting to tell the scripters "you can now decide how much > memory to allow, and that way you are certain it will report the amount you > have set", as much as it is tempting to shift the workload of allocating > script memory onto the scripters since LL can't seem do it. > > Remember, we are now going to have limits on a service that didn't have > them before. For the same price. All in the sake of stabilizing the grid. Ok > for me. This will already hurt scripters who will have to adapt bad scripts. > But now we are told we are going to also adapt good scripts as well ! I > repeat, this is unacceptable. > > Marine > > > > On 7 March 2010 03:02, Frans wrote: > >> As for the dynamic vs fixed memory usage. Of course it would make sense to >> have dynamic memory usage, but I haven't seen a response yet on how to solve >> the problem that Kelly described, about scripts suddenly running out of >> available memory to use, when they fill up lists with info, etc. And break >> because of it. Or is this considered not to be a big problem? >> > > > ___ > 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] The Faces Of Client-Side Code
Ricky, there's nothing major wrong with your classification, but you make two breakdowns which actually have no clear demarcation between them: - Your "Client Plugins" and your "Client Extensions" are actually one and the same thing, merely representing two different use cases of the same mechanism. You're trying to distinguish between compiled languages and interpreted languages, which used to make sense in the past. Nowadays, however, all decent scripting / interpreted languages are actually compiled internally (often even having a JIT compiler), and compiled languages are commonly compiled to bytecode rather than to native machine code, so it's largely a matter of presentation in today's world. And a "broad sandbox" makes no actual sense --- if local platform facilities are made available in a sandbox then it's a sandbox with dangerous holes, which rather misses the point of having a sandbox for platform protection. This category of client-side scripts or programs really does not fit the sandboxed model at all. - Your "Dynamic Client Scripts" and your "UserScripts" are one and the same thing too, because the only distinction you make between them is where they come from, which is not a significant distinction in the actual implementation. While we're here eliding distinctions though, it's worth pointing out that sandboxed client-side scripting is easily implemented within a mechanism for non-sandboxed client-side scripting, but not the other way around! This is why Linden's sekrit Firefly project is so completely wrong. Once you have a *client extension* type of mechanism, adding a sandbox within the extension is quite simple, while vice versa it is actually impossible because a working sandbox denies access to local facilities. You would have to punch holes in the sandbox and hence compromise it (a very bad idea), and the choice of languages would be severely constrained for no reason. It would be a dreadful design choice, and not meet the requirements of a highly empowering client-side extension mechanism. Morgaine. = On Sun, Mar 7, 2010 at 7:19 AM, Ricky wrote: > A while back, before the 2.0 announce interrupted our conversation, I had > made a post about what I saw as three different forms of client-side > scripting/plugins/whathaveyou. I've since been convinced that I missed > something. > > So here goes again, with a (hopefully) improved set of definitions: > > Client Plugins - Binaries compiled per-platform and placed in a special > folder in the client directory by the user/admin of the client's > installation. > These should have no security restrictions, and should have access to any > file on your computer that the system allows, and access to any internal > process of the client. > Provides the ability to build parts of the client without recompiling: > eg. Client-side script interpreters, better joystick support, expose further > public APIs via sockets or whatever, etc. > Also is free to access system libraries, such as OpenGL, windowing > toolkits, etc. > > Client Extensions - Interpreted code packages placed in a special folder in > the client directory by the user/admin of the client's installation. > These should run in a broad sandbox: Limited local disk access (max > datastore size, etc.) to a special file in the local user folder. Eg: > ~/.secondlife/slfirst_lastname/extensions/extensionname.eds (Extension > DataStore) But can still access much the same client hooks as the Plugins. > Provides fast prototyping, and lower entry difficulty, than Plugins, but > will most likely not have the freedom to tap into a lot of system stuff. > Also will not typically run as fast or in as little memory space as the > binary plugins. > > Dynamic Client Scripts - Interpreted scripts loaded from the server via the > server-side permissions system. > May still need a better name... > Could be stored in Notecards and a server-side script could petition, via > llRequestPermissions, to be able to request that the client download the > notecard named via a llLoadClientScript(string name, integer channel) or > similar command. The notecard would then be downloaded by the client and the > plugins/extensions that had registered as able to interpret scripts would > then be queried as to their ability to understand the code, and the one that > answered with the most certainty could be given the task. Some sort of > first-line header in the notecard would help this process along. > Executed within TIGHT sandboxing: Limited, or no access to local disk > storage, and limited to tasks such as drawing on the HUD layer of the GUI, > creating floa
Re: [opensource-dev] The Faces Of Client-Side Code
User perceptions are completely orthogonal to the engineering issues here though, Ricky. We could certainly make all use cases look entirely uniform from a user perspective if we wanted to, but we don't advocate that because the security and responsibility issues are so different in the two (and only two) cases. This is why we separate this area into wholly sandboxed and wholly non-sandboxed parts. The non-sandboxed "viewer extensions" are always "run at your own risk". They are acknowledged to be inherently dangerous because they are powerful, just like every other native platform executable. You bear the full and explicit responsibility of deciding whether to trust them or not when you install them or accept them, and this applies regardless of how transparently they arrived and/or are installed (eg. Firefox add-ons are fairly transparent). And just as with any other executable that you download off the net and choose to execute, if the program sells your spouse and kids into slavery and exchanges your house for 500 Britney Spears albums, the responsibility for having misplaced your trust is yours and nobody else's. In contrast, sandboxed programs would implement "world extensions" within the viewer without needing to touch local PC facilities. Because they don't need local access they can easily be sandboxed with a good degree of confidence in the strength of the sandbox walls, *bugs and exploits excepted *. To some extent (but not fully), this means that trust in sandboxed code can be assigned automatically by those who do not possess a well developed sense of risk and of program frailty, nor an awareness of programmer fallibility and human malevolence. It also means that if the designers of the sandbox imply that it is strong and that your trust can be given automatically to sandboxed scripts, then you might well have recourse against them when your 500 Britney Spears albums arrive. In practice, these two categories are hugely different in human impact, even if implemented using common infrastructure plus an optional sandbox. Of course it's possible to find subclasses within each of them and it's possible to find commonality between them, but this serves little purpose, and if it obscures the risk differences then it becomes highly dangerous. Morgaine. === On Sun, Mar 7, 2010 at 5:09 PM, Ricky wrote: > Carlo, both you and Morgain make very good arguments as to why various > parts I separated are, technically, the same. However, while I understand > that Dynamic Scripts (loaded from serverside) and UserScripts are completely > the same thing (just like in a browser, the JavaScript loaded from > the server-side alongside the web page, and GreaseMonkey UserScripts are > both just seperate views of the same thing,) they are made distinct in > the terminology here due to the fact that a user will see a difference. > > I also understand how you would see the Extensions and Plugins as also > being nothing but the same thing. Setting up an IPC layer in the C++ is > absolutely required, but I don't think that we need to put /multiple/ ways > of connecting plugins into the code hooks. I'd prefer the most direct > method of using a form of dynamically loaded shared library that implements > a common object Interface that the client then calls. This provides the > most direct, most capable interface. It is also not very abstract, as the > underlying code could easily change in such a way as to break the interface, > but that is a common enough problem for any of the plugin designs I've met > with. As I mentioned before, one of the first of these plugins could easily > be one that exposes a socket based interface for a more abstracted system, a > la Morgaine's design. > > Note that while most users may not explicitly notice a difference between > Plugins and Extensions, as they can easily blur use-cases, they are hugely > different in the back-end. Consider Plugins to be ways of writing a "patch" > that provides a new feature to the client. Extensions could do the same, > but are out on a distinct abstraction layer provided by a variety of > plugins. > > For Dynamic scripts and UserScripts users will see a distinct boundary, > even though there is no such boundary in the back-end. One is for the > server-side coder to do things to my client, while the other is a way for me > to easily do things to my client. Again, these can be provided by various > plugins/extensions. > > And while I put no sandbox restriction upon the Plugins, that shouldn't be > considered to mean that the plugin designer couldn't decide to sandbox their > own code. I'd love to see the Shared Media re-factored into a plugin that > provides a sandboxed environment
Re: [opensource-dev] Client Plugin System Design
wer is accepted so that sandboxing can provide security, this sandboxing can only ever be relatively weak *software sandboxing* because the plugin code and data lie within the address space of the host application. This contrasts markedly with plugins implemented as system processes, which are backed by the much stronger guarantees of isolation provided by the system's hardware MMU, even if plugins are written in bare-metal C/C++. - Because DLE runs plugins as part of the host application, the standard system tools for working with processes cannot easily be used. Even basic facilities such as killing a script would have to be implemented from scratch within the multiprogramming environment, instead of using the existing operating system kill command. The same applies to profiling, performance monitoring, debugging, optimizing, and so on --- all are much more difficult within the host application, or not even viable. (An example of this problem is provided by SL's Mono subsystem, which *still* has no means of unloading sim-side Mono assemblies after script termination, simply because the unload facility was never written.) - DLE requires that user programming of plugins be done in an environment of special calls to the host application so that plugins can cooperate properly with the host's code, and this has to be done very carefully to avoid damaging the host. It is very distant from the simplicity and safety of programming external processes, which can use stock textbook styles and the normal libraries for the language. DLE really needs client-side plugin programmers to be relative experts, while process-based plugins are safe enough for a much larger and less expert audience to program. This list of negatives could easily grow a lot longer, but to bring it to a close I'll just mention that DLE has some advantages too, but they are remarkably few in number. The most important one is that the interface to viewer facilities can be very thin and hence fast. For example, if the purpose of a plugin is to render fast GL graphics then DLE is a good approach, albeit for single plugins only. In addition, as long as no concurrent execution is required, implementing DLE can be done in under a day (at least for Lua), plus a few weeks for defining API functions. It's really that simple. However, the vast majority of plugin applications do not require bare metal speed, and what's more, concurrent execution of plugins is a mandatory requirement. This makes the tradeoff of pros versus cons weigh massively against the DLE approach for our application. Morgaine. PS. With regards to "Networking code in every plugin just to connect to the client", networking is made available by the operating system to every process through system calls or system subroutines, ie. the thinnest interface possible. There is no bloat or overhead involved. Particular languages sometimes pretty up the system interface a little, but these bindings do not normally introduce any significant overhead. Throughput and latency of socket communications is not a significant issue either --- I've measured them in an environment which emulated this design pattern, and the level of performance might even suit some rendering tasks. == On Mon, Mar 8, 2010 at 2:19 AM, Ricky wrote: > So far, barring any LL concepts, we have (as far as I know so far!) two > designs of plugin system: > 1: Socket-based plugins - as suggested by Morgaine. > 2: D-Bus or similar existing IPC tool. > 3: C++ Dynamically Shared Objects - my suggestion. > > Morgaine's design has a couple advantages that I can think of: Namely, a > distinct lawyer-approved separation of code allowing the plugins to be > released under different licenses, and a fairly stable target to design > around, meaning the socket API wouldn't typically change a lot across > releases, plugins also could be built into other external packages that > interface with the socket API to provide massive amounts of integration. > However, it's disadvantages come along: Networking code in every plugin > just to connect to the client, separate processes that have to be launched > by something - presumably the client code, but not always... > > I'm not too sure about the D-Bus design, there hasn't been much discussion, > other than it seems a lot like Morgaine's suggestion to me, just an > available existent re-usable tool. That can be a good thing, as we wouldn't > have to worry about the protocol, it would be already done. > > The last option is one I've seen references to across the 'net. All that > would be written in the client software is one or more Interface Objects > (those familiar with polymorphic design are very familiar
Re: [opensource-dev] Client Plugin System Design
Lua provides a fine example of Direct Language Embedding. The language was designed expressly for being embedded in a host application as well as for being extended with calls to other languages. It's no surprise then that it is very clean and simple to use in this way. I like Lua a lot. Unfortunately, as you know from your own work, Rob, there is a big difference between using an embedded language inline with its host application's main or single thread of execution, and turning the language into a concurrent execution environment that can run multiple user scripts at the same time, which we need here. As I explained briefly to Ricky, to achieve the latter requires a multiprogrammed runtime to be created within the viewer, using either one of the multitasking approaches such as preemptive timeslicing plus a scheduler or alternatively coroutine-style cooperative yielding, or else using system threads to run multiple language runtimes concurrently. Whichever approach is used, a concurrent runtime would have to be added to the viewer to handle either the internal multitasking or the interations between system threads, and on top of that, one would then add an API to the world-related aspects of the viewer. It would be a non-trivial job. In the case of Lua, the clear winner for DLE is to spawn a system thread running a Lua VM for every Lua user script that needs to run, and let the system worry about executing them concurrently and scheduling between them. That's easy, but much hard work remains because simply having N separate Lua scripts running without interacting with the viewer is of no use at all, so a communications system needs to be built within the viewer to manage its interactions with these concurrent threads. (Letting each Lua script access any needed viewer code directly and concurrently through a simple C++ binding is of course not viable --- the viewer is not internally thread-safe, and locking calls gets us deep into concurrency horrors.) I like using Lua as it is designed to be used, running inline with an application's main thread of control (ie. no concurrency). I use it for flexible configuration and very easy testing of applications. Lua is also quite well suited for implementing large chunks of applications, everything excluding those functions that need to run at bare-metal speed like rendering. For example, it would be perfectly viable for the entire 2D GUI of the viewer to written as a suite of Lua scripts, each one invoked from C++ only when the appropriate GUI element requires attention. However, these scripts would have to be short and non-blocking --- one would not have the freedom of writing Lua scripts in the normal way with arbitrary loops and extended calls to external facilities, and multiple Lua scripts would not run concurrently. This is why the process-based approach is being recommended. It eliminates the work of implementing a multiprogrammed environment for scripts, letting the system do all the hard work (*really* hard work, because of concurrency). Instead, it requires socket handling, but that is quite short and simple sequential code. Depending on how one wishes to serialize communications, the amount of work here can vary --- calling JSON encode/decode routines is typically very easy, but handling buffering and exceptions can introduce some significant work. That's the in-viewer work overhead of this approach: socket handling and serialization. It's a *lot* less than the work overhead in DLE, and the flexibility that results from users being able to write plugins in any language they want and calling any libraries they want and using normal programming styles is a major win. Morgaine. === On Mon, Mar 8, 2010 at 10:44 AM, Rob Nelson wrote: > On Sun, 2010-03-07 at 18:19 -0800, Ricky wrote: > > So far, barring any LL concepts, we have (as far as I know so far!) > > two designs of plugin system: > > 1: Socket-based plugins - as suggested by Morgaine. > > 2: D-Bus or similar existing IPC tool. > > 3: C++ Dynamically Shared Objects - my suggestion. > > You forgot interpreted scripts, such as Lua. Already implemented and > working in the Luna viewer. A lot easier to develop for, as well, since > users don't need to have an API to use it. All they need to know is how > to make it work and where to dump their files. > > The largest issue is sandboxing and threading, actually. I still have > to make an override for the io.* functions that will not access > materials outside of lua/data or the plugin's folder, and creating a > working event queue is becoming a major pain in the neck. > > Fred Rookstown > Luna Viewer (http://luna-viewer.googlecode.com) > > ___ > Policies and (un)subscribe information available here: > http:
Re: [opensource-dev] Client Plugin System Design
Yes, there is a way, Tigro. In the Multi-Process Client<https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft>design that we started back when AWG was active, we loosely defined "Facility Optimization", which would be done mainly through communication * accelerators*. The general idea is that if profiling shows that the job being done by a socket-linked plugin is being held back by socket throughput or latency or by serialization overheads, then an *accelerator *pathway can be added between viewer and plugin. In most cases this would involve setup of a shared memory segment for exclusive use by the viewer and this one single plugin. Every plugin requiring such acceleration would have its own "private" shared memory segment, shared only with the viewer, not with other plugins. Using shared memory means that socket and serialization overheads vanish completely of course, since data transfer can be done by reference. As always though, there is a tradeoff: the viewer is now involved in two-party multiprogramming with respect to each accelerated plugin. As anyone who has worked in concurrency knows, here be dragons. Nevertheless, it is perfectly viable for occasional, narrowly-defined high speed tasks. This would require special programming within the viewer, both to manage shared memory segments and also to implement the by-reference communications system, for instance using mailboxes or atomic variables. While viable, it would not be easy, and one might wish to question (on a case-by-case basis) whether dynamically loading a shared native code library might not be more appropriate. Still, such accelerators could be used if desired, and if they are implemented *transparently* so that any plugin could have its socket pathway accelerated on demand then this would be a major win for all data-intensive plugins. Morgaine. On Mon, Mar 8, 2010 at 1:51 PM, Tigro Spottystripes < tigrospottystri...@gmail.com> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Would there be an approach that would allow both all the benefits you > mention, plus letting the process based plugins have access to the bare > metal performance? (somthing like a way to have the plugins instruct the > client to add the desired processing routines to it's per frame cycle or > whatever) Perhaps an hybrid approach, where with secure sockets > communication and perhaps user intervention (a dialog to grant or deny > access to an specific plugin) the external plugins could interface with > the client guts like DLE plugins? > > Actually, how much is the performance loss if the plugins aren't of the > DLE kind? > > On 8/3/2010 05:22, Morgaine wrote: > > Ricky, I'm not sure even where to begin, because your proposed solution > > is simply direct embedding of one or more scripting language systems > > into the address space of the viewer. This ignores every single > > advantage of process-separated plugins and replaces them with a catalog > > of problems that could fill a book. > > > > Direct embedding is what everyone does when they want a simplistic > > sequential scripting facility for configuring or testing a host > > application. We haven't proposed it ourselves not because we've had a > > brain lapse and can't see the simplest solution, but because the > > simplest solution is a complete disaster when misapplied as a general > > scripting facility for user-written extensions. I regularly embed Lua > > into host programs your way, but using that approach here would have so > > many disadvantages and so few advantages that I have avoided it > > intentionally. > > > > I'll try to summarize some key issues for you, although this will leave > > much unsaid. Let's call the conventional approach Direct Language > > Embedding, or *DLE* for brevity. > > > > * Unlike process-based plugins, DLE normally provides no concurrent > > execution. This means that if you want your plugins to execute > > concurrently you will have to implement either multitasking or > > threading in the viewer, both of which involve shared-state > > multiprogramming. > > > > * Shared-state multiprogramming is hard and error-prone because of > > race conditions, non-determinacy, atomicity and locking, > > transactional integrity, as well as deadlock, livelock, and > > various other highly unfriendly critters. I'm not going to > > justify this further here as it would take too long, but I did my > > research in this area, and anyone who thinks it's not hard needs > > to study the topic another 10 years. A reli
Re: [opensource-dev] Client Plugin System Design
Indeed, Lawson. You may have seen it, but I provided a little more detail about accelerating plugin communications using Shared Memory segments in my answer<https://lists.secondlife.com/pipermail/opensource-dev/2010-March/000633.html>to Tigro. In practice it's not easy to come up with an SM-accelerated path mechanism that preserves the semantics of communications on the socket path transparently, so I expect that these two paths would be kept separate. It wouldn't be too hard to implement an SM-based path into the viewer in parallel with the socket-based channel. I expect that most of the design battles would be about what shared data model to use. A sequential mailbox carrying by-reference payloads? A DOM-like structure? Locking with strong conventions? Lock-free update techniques? Software transactional memory? Retro semaphores and condition variables? Single assignment and no mutable state? Unfortunately all of these mechanisms have disadvantages and dangers --- there is no silver bullet in this area. The only way to win the SM multiprogramming game is to not play it, which is where we came in: socket messaging with no shared state. It's unfortunate that, occasionally, we have to break this rule for performance reasons. Morgaine. = On Mon, Mar 8, 2010 at 6:40 PM, Lawson English wrote: > Morgaine wrote: > >> >> >> PS. With regards to "Networking code in every plugin just to connect to >> the client", networking is made available by the operating system to every >> process through system calls or system subroutines, ie. the thinnest >> interface possible. There is no bloat or overhead involved. Particular >> languages sometimes pretty up the system interface a little, but these >> bindings do not normally introduce any significant overhead. Throughput and >> latency of socket communications is not a significant issue either --- I've >> measured them in an environment which emulated this design pattern, and the >> level of performance might even suit some rendering tasks. >> >> > When extra speed is needed, the shared memory design of the media plugin > can be used to augment/replace socket connections. The only caveat there is > that each OS has a limit on how many shared buffers can be used per > process/machine. > > On Mac OS X, without some superuser tweaking and maybe a restart, it's 8 > per process and 32 per machine. Other *nix have more I think and I have no > idea what Windows allows. Regardless, its something that should be used > sparingly. > > > 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] Snowglobe as an mixed reality platform
I would wish everything to be as honest and open as you've described it, Merov. The problem is that the open source / TPV community has been battered around the head too much recently (by factors outside of your control, I'm sure), and when the answer to everything seems to be "No" except when it involves a corporate partner, it doesn't lead to comfortable thoughts. The situation has been *SO* bad recently that even small hints like your "*it might need preliminary work being done on the client-scripting side of things*" are a significant win --- that's how depressed the situation is currently. Yet notice that you don't even state that the community will have any say in it --- your remarks are entirely consistent with Firefly continuing as a secret internal project and all community requirements being ignored. "Must try harder." Hopefully this will be remedied, and the spirit of cooperation rekindled. Client-side scripting is a bit of a weather vane for how well relations are progressing, and it's quite easy to turn thing around. It just needs some good will to be shown, and open dialog to return. There was going to be a new openness after Viewer 2.0 was released, wasn't there? We heard that said multiple times around the end of 2009. It still remains to appear though. Morgaine. = On Mon, Mar 8, 2010 at 9:42 PM, Philippe (Merov) Bossut wrote: > Hi Morgaine, > > I'm surprised and disappointed you're reading so much into this. Personal > (and irrelevant) feelings aside, my answer was motivated strictly by the > following: > - There is an already existing set of code with experimental results and it > looks very nice indeed. > - There's a chance all this good work might get lost forever if it doesn't > find a host. > - According to Tuomas, it's relatively isolated on the fringe of the code > and doesn't need rearchitecture. > - The Snowglobe community is certainly the best qualified to look at this > code and see how we could merge it if at all. > > Based on that, the minimum we can do as a community is to show respect for > the work done by Tuomas and his group and welcome them. I see no reason to > turn them down and you haven't provided any BTW. > > Note that I'm not offering to merge the project "as is" but lay out some > steps for Tuomas to take so that we can collectively study that code, > namely: log something in JIRA and attach a patch so we can look at the code. > > I hope others on the list feel the same and that we'll find some enthusiast > folks to look into Tuomas project and see if and how it can fit into > Snowglobe (hint: I'm unlikely to have the bandwidth to do this). The fact > that it might need preliminary work being done on the client-scripting side > of things is, IMO, a plus (give us something tangible to gauge our > thinking). > > Regards, > - Merov > > > ___ > 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] Third party viewer policy: commencement date
I believe that they're seeking better-informed legal counsel on GPL compliance first, before redrafting the TPV. The first version conflated users, viewers and developers so terribly that GPLv2 clause 6 was left in tatters. Joe's phrasing is the only one that makes the necessary separation so far. I hope he has a hand in the redraft. :-) Regarding commencement, that was just typical product manager silliness, announcing release or commencement dates before something is ready. File under ignore. Morgaine. = On Tue, Mar 9, 2010 at 2:11 PM, Boy Lane wrote: > It has been 14 days since the initial draft of the 3PVP was published and > we > were told it will be reworked to include comments, concerns and > suggestions. > Two weeks have passed since and besides a FAQ that also says the policy is > being worked on there have been no news. > > As this is a mission critical question for everybody involved in client > development: > What is the status of the Third Party Viewer Policy? Do we have to assume > that the current version is binding and/or when will an updated version be > available? > > Thanks! > > > ___ > 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] Script Memory Management Algorithm
Carlo +1. Explicit pre-allocation of memory by users has to be one of the silliest and most regressive "improvements" appearing in SL for a long time. It's a waste of memory, it takes us back decades, and it's a burden on users. So why do it? "Because we've decided to, full stop." -- seems to be the prevailing M.O. Morgaine. On Tue, Mar 9, 2010 at 1:26 PM, Carlo Wood wrote: > This is exactly the kind of reaction that drives me away from here. > > I propose a simple way get FOUR times the memory for all the scripts, at > no other cost than adding some malloc code to your mono engine. > > And you simply say, "This is what we ARE doing, we're not going to change > that". > > Why this immovable stubbornness about internal development decisions? > > In case with the below you mean to say "allowing people to set ammount > of memory at which their scripts crash, up front, is as good," then > read the past posts on this list again. > > People say that it is NOT, by FAR not, as good. Scripters shouldn't > have to manually figure out the maximum ammount of memory their scripts > can possibly use and use that as the fixed ammount of memory that > their script reserves. That was last done 10 years ago. Just have the > server take care of this: give a script a minimum, and when it needs > more, give it more. No hassle for the users. > > On Mon, Mar 08, 2010 at 09:46:44AM -0800, Kelly Linden wrote: > > We are not out to write a new malloc for mono. What we have is a system > that > > throws an exception when the memory used by the script hits a certain > threshold > > (64k currently). This exception is caught so we can "crash" the script. > The > > future small scripts and big scripts projects will add new functions to > set and > > get this threshold value, allowing scripters to effectively control how > much > > memory is reserved for their script. We will continue to use mono's > default > > memory management within the reserved memory thresholds. It is a much > simpler > > problem to solve. > > > > - Kelly > > > > On Sun, Mar 7, 2010 at 5:50 AM, Carlo Wood wrote: > > > > Lets assume that the *average* script uses > > 8 to 16 kB of real memory. LL's design allocates > > 64 kB regardless, leading to an overhead of > > 400 to 800% (meaning they need to buy 5 to > > 9 times the memory that is theoretically needed). > > > > In that light, I gave it some more thought, and > > think something as complex as my rmalloc's algorithm, > > with it's 19% overhead, isn't needed (note that > > it's both faster than gmalloc as well as three > > times more efficient; so complexity is not always > > a bad thing ;). > > > > Nevertheless, in this case, since the scripts > > use a maximum of 64 kB, you can use the > > following design: > > > > Let each allocated block be a power of 2 > > kilobytes, with a maximum of 64 kB (and a > > minimum of 1 KB, or 4 if even the tiniest > > script needs that). > > > > It is easy to see that this would lead > > to an overhead of 25% on average per > > allocated block. > > > > We'd still have to deal with "holes" of a > > full 64 kB where blocks became totally > > unused, but normally scripts in objects are > > started all at once when a sim reboots, and > > only seldom stopped. The scripts that will > > most likely attribute to random starting > > and stopping of scripts will be the scripts > > in attachments. A worst case scenario would > > be one where there are 50 avies in a sim > > (during a meeting), then a new avie enters > > with some scripts which need to be allocated > > at the top of the heap; then the previous > > 50 avies leave. That would create a hole > > in the heap of the size of all the scripts > > of those 50 avies. If script memory would > > be relocatable, then this problem doesn't > > exist of course. I can't simply estimate > > the average overhead caused by this, but > > because the algorithm described here is > > basically the one used by gmalloc (which > > in my test used 62% overhead) I'm pretty > > sure that it will be less than -say- 100% > > overhead; still 4 to 8 times more efficient > > than the current design on the table. > > > >
Re: [opensource-dev] Third party viewer policy: commencement date
At any given point in time, one viewer is more stable than another, and at another point in time, it's the other way around. This is perfectly normal, and blanket statements about superior stability make no sense ... especially when they share common code! :-) If anything, Snowglobe could well be more stable over time, since any bugs probably won't last long because they tend to get patched rapidly and a new tagged version released. In contrast the official LL viewer gets released infrequently. One shouldn't read too much into PR or advocacy statements anyway. Morgaine. = On Tue, Mar 9, 2010 at 11:11 PM, Thomas Grimshaw wrote: > It's the truth. Snowglobe is unstable. > > ~Tom > > Armin Weatherwax wrote: > >> I am simply pointing out that they are NOT compatible with the GPL. > >> > > GPL compatible or not - the sentence "The Snowglobe Viewer [...] this > > viewer may be somewhat less stable than the official Second Life > > viewer"( http://viewerdirectory.secondlife.com/ at 2010/03/10 00:06 > > GMT+1) is a slap into the face of anybody contributing bugfixes to the > > secondlife codebase. > > > > Armin > > > > ___ > > 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 > ___ 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] Third party viewer policy: commencement date
*If only* new features got into Snowglobe faster. :-) The only things that seem to get in fast are bug fixes. And of course IBM-sponsored code. Admittedly, the rate is somewhat faster than into LL's main viewer ... but then, it could hardly be slower! :-) Talking about "LL's main viewer" ... why doesn't it have a name? Morgaine. == On Wed, Mar 10, 2010 at 12:26 AM, Gareth Nelson wrote: > Don't new features get into snowglobe faster too? Thus more potential for > bugs > > On Wed, Mar 10, 2010 at 12:15 AM, Morgaine > wrote: > > At any given point in time, one viewer is more stable than another, and > at > > another point in time, it's the other way around. This is perfectly > normal, > > and blanket statements about superior stability make no sense ... > especially > > when they share common code! :-) > > > > If anything, Snowglobe could well be more stable over time, since any > bugs > > probably won't last long because they tend to get patched rapidly and a > new > > tagged version released. In contrast the official LL viewer gets > released > > infrequently. > > > > One shouldn't read too much into PR or advocacy statements anyway. > > > > > > Morgaine. > > > > > > > > > > > > = > > > > On Tue, Mar 9, 2010 at 11:11 PM, Thomas Grimshaw > > wrote: > >> > >> It's the truth. Snowglobe is unstable. > >> > >> ~Tom > >> > >> Armin Weatherwax wrote: > >> >> I am simply pointing out that they are NOT compatible with the GPL. > >> >> > >> > GPL compatible or not - the sentence "The Snowglobe Viewer [...] this > >> > viewer may be somewhat less stable than the official Second Life > >> > viewer"( http://viewerdirectory.secondlife.com/ at 2010/03/10 00:06 > >> > GMT+1) is a slap into the face of anybody contributing bugfixes to the > >> > secondlife codebase. > >> > > >> > Armin > >> > > >> > ___ > >> > 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 > > > > > > ___ > > 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 > > > > > > -- > “Lanie, I’m going to print more printers. Lots more printers. One for > everyone. That’s worth going to jail for. That’s worth anything.” - > Printcrime by Cory Doctrow > > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > ___ 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] Third party viewer policy: commencement date
bute GPL code then it might well not be GPL compliant at all. This is a fine point that might have to be tested in court, because it's not obvious if it's a restriction on the freedom to modify and distribute or a restriction on usage. Is the GPL developer being restricted in his modification or distribution of the GPL program? Well it seems like it, but the best way of avoiding legal finessing is to simply declare all the restrictions as applying at the time of connection to SL, and not at the time of modification or distribution. Being GPL-compliant is really a very simple matter of using the right language, and making it clear that the restrictions are *usage restrictions*, not development nor distribution restrictions. Joe Linden demonstrated how to phrase it perfectly last week. As I said back then, if he were to rewrite the TPV document, we could probably all go home early. ;-) Unfortunately, there is yet another problem with the TPV document --- an attempt to make developers liable for what happens when their viewers are used in SL by others. Apparently the two capitalized paragraphs of GPLv2 clauses 11-12 are not written in large enough letters: - *NO WARRANTY* - *11.* BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. - - *12.* IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. If the TPV document is claiming that GPL developers are responsible for something that the "*NO WARRANTY*" clause explicitly disclaims, then this would be yet another source of GPL non-compliance. Unfortunately what the TPV is claiming is quite unclear. So, no Tayra, GPL compliance is not guaranteed simply by chucking the source code at us. The GPL has some very strong additional requirements for compliance, and we're not in the clear yet. This is why LL is seeking specialist legal counsel that understands the GPL, we are told. The first draft seemed quite unaware of the GPL's requirements and guaranteed developer freedoms. Morgaine. = On Tue, Mar 9, 2010 at 8:12 PM, Tayra Dagostino wrote: > On Tue, 9 Mar 2010 14:47:35 + > Morgaine wrote: > > > I believe that they're seeking better-informed legal counsel on GPL > > compliance first, before redrafting the TPV. The first version > > conflated users, viewers and developers so terribly that GPLv2 clause > > 6 was left in tatters. Joe's phrasing is the only one that makes the > > necessary separation so far. I hope he has a hand in the redraft. :-) > > > I think yoiu've misreaded the TPV policy, no GPL violation, viewer > code is GPL, you can take a copy from svn, manipulate it, patch or > mood, rename it, all GPL let u do with it (and consequential charges > for a developer who work on a GPL code) > > TPV is like an addendum to TOS, if you want use Linden Lab grids you > should follow some rules... this is server side, no viewer code > involved... the Linden services aren't GPL... > ___ 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] Request for comments about llSetAgentEnvironment / SVC-5520
On Wed, Mar 10, 2010 at 9:59 PM, Rob Nelson wrote: > Sigh. > > I've tackled this in my viewer with a plugin, and yet no one seems > interested in the plugin system I'm using; Everyone's hellbent on > binary plugins. > That is so totally not the case, Rob. Virtually nobody other than Lindens are "hellbent on binary plugins", and Lindens are doing so in secret in order not to have to justify themselves to the community. It's clear that they want a *fait accompli*. that we will have no opportunity to influence, and then they will pretend that they are good open source citizens by dumping the sources on us, too late to undo their appallingly bad design choice. Outside of Lindens and their business interests, nobody who is technical and moderately sane and is not a sociopath is likely to support automatically downloading *binaries* that then execute on your computer. It's the height of irresponsibility to create such a mechanism, in full knowledge that no sandboxing is perfect and that therefore residents' computers will be compromised by malicious people. Even their fully-managed server-side systems suffer exploits regularly --- the prospects for security disasters in the far more varied client-side environment are immense. The Lindens doing this are fully technically aware of the dangers, yet they are still doing it. It's totally unconscionable. And I'm sure the botnet operators are rubbing their hands in glee at the prospect. "Rock on Lindens!" Morgaine. == On Wed, Mar 10, 2010 at 9:59 PM, Rob Nelson wrote: > Sigh. > > I've tackled this in my viewer with a plugin, and yet no one seems > interested in the plugin system I'm using; Everyone's hellbent on > binary plugins. Feel free to use the code, I haven't added the GPL2 > headers yet. > > > http://code.google.com/p/luna-viewer/source/browse/trunk/indra/newview/lua/Hooks/Windlight/_init_.lua > > Fred Rookstown > > On Wed, 2010-03-10 at 16:05 +, Opensource Obscure wrote: > > Yesterday Jopsy Pendragon submitted this feature request > > to the public JIRA: > > > > llSetAgentEnvironment( key agent, [ param list ] ); > > http://jira.secondlife.com/browse/SVC-5520 > > > > I'd like to hear your comments. > > > > I'm not competent enough to say if the request is > > feasible as it's proposed, but the proposed LSL > > implementation would be fine for me. > > > > This complements other old PJIRA issues, like > > > > Estate / Sim Windlight preset / day cycle options > > http://jira.secondlife.com/browse/VWR-7677 > > (450 votes) > > > > and many others - see meta-issue > > http://jira.secondlife.com/browse/SVC-2736 > > > > Please provide feedback and vote as you feel appropriate. > > > > New, powerful Light/Shadows features are going to > > appear into the official SL viewer; > > the number of users with hardware capable of > > running advanced lighting features grows; > > so SL land owners need control over this, and IMHO > > they will need it even more in the future. > > > > > > bye > > Opensource Obscure > > ___ > > 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 > ___ 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] Snowglobe 2.0^H^H^H1.3 way forward?
The answer to all of these UI issues is simply client-side scripting. Quite literally anything and everything would be possible through user-controlled extensions, far beyond the very low-powered UI features in Viewer2.0. Both novices and experts would have been catered for, as well as everyone in between, simply because of the great flexibility of local scripts. Instead of this, LL are working on a secret security minefield in their internal Firefly project which can't provide this kind of flexibility, and in the interim we have this unhelpful hardwired 2.0 UI being quite literally forced on us --- if we don't adopt it, we'll be "signing up for an awfully large chunk of porting work", to quote a Linden's own words. LL's relationship with the open source community has really gone off the rails recently. Morgaine. On Fri, Mar 12, 2010 at 5:35 PM, Matt White wrote: > On Fri, Mar 12, 2010 at 11:25 AM, Argent Stonecutter > wrote: > > (Sorry Argent, didn't mean to reply directly to you... resending this > to the whole list.) > > > * chat bar focus > > * chat bar size > > * simple chat overlay (single background element, no badges, etc) > > * Location *on title bar* so you can get rid of the browser-style bars > > * IMs in a window. REALY in a window. > > * chat bar on chat floater > > * No sidebar > > > > What have I missed? > > Bring back the old profile window. When I have a few "interesting" > people in the sim I'll open up their profile and leave it minimized. > If/when I need to start filing ARs / estate banning / etc, the correct > spelling of their name is a simple copy/paste away. > > During the "fog of war" my spelling often gets pretty poor. > > -- > Matt White / Bunny Halberd > ___ > 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] Request for comments about llSetAgentEnvironment / SVC-5520
Soft, you misread what was written. I carefully worded the sentence containing the word "sociopath" to exclude Lindens --- please note my words "*Outside of Lindens and their business interests*". The word "sociopath" was aimed specifically at the botnet operators and criminal organizations who exploit innocent people through exploits on their PCs, and well as covering griefers. I would hope that you too consider at least the criminals as "sociopaths", as I do. The parts that applied to Lindens were the paragraph before and the paragraph after, and the line about responsibility. I believe that the company has business motives for doing what it is doing in secret, and that it is willing to sacrifice open source principles and community involvement to achieve those business goals. That's all. Pointing out the security dangers here is the responsible thing to do. I hope you agree with that as well, and would encourage all critical comments about security. Unfortunately you've tied our hands by making that project internal and secret. Morgaine. == On Fri, Mar 12, 2010 at 6:10 PM, Soft Linden wrote: > On Fri, Mar 12, 2010 at 9:34 AM, Morgaine > wrote: > > > > Virtually nobody other than Lindens are "hellbent on binary plugins", and > > Lindens are doing so in secret in order not to have to justify themselves > to > > the community. > > I don't know the details of this work. I do know that ascribing these > kinds of motives instead of asking "why" questions is a good way to > get yourself written off as a hurdle instead of a resource. That later > rhetoric about "sociopaths" and some of the earlier comments make it > clear that input is going to be unpleasant and ultimately > counterproductive. If you read back over your message, could you see > the outcome being a dev going out of the way to involve you in their > work? > > Civil, objective discussion with well-backed positions would signal > that the community's going to be a resource that can make a Linden > more productive in his work. Where that's the case, they would be nuts > not to go to the list as soon as possible. But colored as the list has > been, I know I wouldn't even want to talk more than I had to about a > Snowglobe-specific change. It would just get in the way of getting > things done. > > I'm pretty sure you've also sat in on Q's office hours more than once. > What did he say when you asked about plugin decisions there? I expect > he'd have answered with something other than psychopathy and > conspiracy. > ___ 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] Nurturing an open source community; was: Request for comments about llSetAgentEnvironment / SVC-5520
I believe that Linden Lab is quite clear that it wants an open source community. I also believe that, unfortunately, it does not quite realize that when the Lab and the community become partners in an open source project, that there are strings attached. Morgaine. == On Fri, Mar 12, 2010 at 10:44 PM, Mike Monkowski wrote: > Soft, > > It is not clear whether Linden Lab wants an open source community. The > impression from this side is that Linden wants help fixing bugs, but not > fixing features, but if that requires importing a feature or two, then > it's worth the trouble. > > It is also quite clear that Linden does not want any help in design. > The user experience office hours haven't been hosted by Lindens for more > than a year now and Lindens rarely attend the extension of those > meetings now being run by residents, particularly Jacek Antonelli. > (Thank you Jacek. I'd nominate you for a Hippo Award if Linden still > gave Hippo Awards.) > > You spoke of "understanding each other's needs." I would wager that > there is a near unanimous view in the community that Linden does not > understand the needs of an open source community. Certainly threats of > "throttling" are not among them. Lindens usually speak as if the > failure to understand is entirely on the side of the contributors, and > Lindens are not at all at fault. > > You say "a totally healthy open source project usually can be developed > completely in the open," but this project has never been developed > completely in the open, and the trend is strongly toward closed > development. > > If we understood how we were being "obstructionist" and "in the way of > business," then a conversation could develop. I, personally, don't know > what you are referring to. > > At the moment, the SL open source community is very close to taking the > 1.23.5 code, pulling in a few features from 2.0, and permanently forking > from the standard viewer. I don't think that's good for anyone. > > Mike > > Soft Linden wrote: > > This is a company with an open source project, not an open source > > project with a company. If the community becomes obstructionist enough > > to get in the way of business, the open source part will get throttled > > back. If the community's being largely helpful, open source > > involvement is advanced. I spoke up because this conversation was > > looking a lot like something that could lead to throttling while > > accomplishing nothing. > >... > > A totally healthy open source project usually can be developed > > completely in the open, and in a way that's aligned with everybody's > > interests. But that takes an active commitment on all sides, both in > > terms of composure, and in understanding each others' needs. > ___ > 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
[opensource-dev] Known details of LL 'Firefly' client-side scripting
Soft, I answered your post (enclosed below) quickly on Friday 12th to correct the unfortunate misreading of the words I had written, as that was rather urgent. I didn't have time then to answer your point about our technical discussions with Q though, as it needed the details to be dug out. Now I'll deal with the specifics of the Linden client-side scripting work, because this is where you invited "well-backed positions". Hopefully you will see that our position is very well backed, because it is based on the information that we were given at Linden OH. On Fri, Mar 12, 2010 at 6:10 PM, Soft Linden wrote: > I don't know the details of this work. > > Whereas OH attendees do know the details, to the extent that they have been revealed to us, so I'll provide this same information for you and others to see. Then we can refer back to the reasons why we need to revisit the Linden design decision. > I'm pretty sure you've also sat in on Q's office hours more than once. > What did he say when you asked about plugin decisions there? > I have indeed sat in on these, more than once, and this is why I know enough about it to be able to make the comments I made earlier. I have my chat log for the OH of 3rd Feb 2010 open in front of me, just to be sure that I am not misremembering anything. Although the discussion contained an hour-long rejection of virtually all critical input, it was also quite informative regarding the *general* nature of the 'Firefly' project, so I'll summarize for you the technical details as accurately as I can, using the original Linden words (shown in quotes) and little else. The following was spread out over an hour: - "We ARE working on client-side scripting; there's a project just getting underway. It will NOT be a 2.1 sort of thing, it's a pretty big project." - "My goal is to create a platform for plugin UI development with a completely open API specification, built on an open scripting platform (almost certainly mono)", "capable of doing anything that the viewer protocols are capable of." - "The viewer that incorporates this scripting platform will be BUILT in the scripting language." - "It needs to have a solid sandbox model (therefore Mono or another robust VM) and a strong, capabilities-based security model." - "Each plugin should be required to request specific caps based on need. In its metadata, it has to say what caps it's going to need. Any attempt to request other capabilities at runtime is rejected, the VM sandbox can control its abilities." - The goal is to provide "a model in which people can trust a plugin." - "There are two layers -- the viewer has a scripting platform and our viewer at least will attempt to prevent requesting the cap. The cap itself, however, is issued by the server." - "Anything the client can do manually will be possible" [for a script as well]. - "This means automation, bots, and accessibility will all be MUCH easier." - "The flip side of this, as morgaine is pointing out, is that we have a lot more hardening to do to regulate access at our servers." - "We shouldn't have to rely on a well-behaved client." - "Sai, you're correct. There are some caps which would be client-side only." - "CPU, what it means is that a plugin that wants to do that has to advertise -- on installation -- that it wants to do that. I'm guessing there won't be much of a market for such plugins." - "And we might decide to restrict access to such a cap to a signed plugin, through a dev api or something." - "The developer platform discussion is still under discussion." - "What babbage is saying is the idea of distributing some inworld scripts to the client." "That's part of the motivation of using Mono client-side." The hour also featured a large amount of discussion about CLR-based languages, all of it predicated on Mono being the single mandatory route to client-side scripting, and clearly indicating that any other language programming would have to go through Mono. Although the above is rather skeletal, it is very clear as far as it goes. It leaves little doubt about how Firefly is intended to work, namely as I described in my reply to Rob Nelson: *a mechanism for running untrusted binaries on user's computers automatically*. None of this was made up, it was based on the information given to us by a Linden, and it is on that basis that we have been making our objections. Given more information we could of course make a more detailed analysis, but this is the best we can do when the rest is a secret. You will note that the binaries run in a sandbox
Re: [opensource-dev] Known details of LL 'Firefly' client-side scripting
Mike, Soft was referring to us on the opensource-dev list as a whole. That's the "we". As to which "our position" is, that's simply the aggregate of what everyone has expressed in this list. People speak for themselves here. If you're not sure what that "community position" is, you have a lot of reading to do. You'll have to start back in February, in the massive thread that was begun by this post of mine on client-side scripting<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/88.html>. The discussion continues, and it's totally open. Morgaine. On Wed, Mar 17, 2010 at 4:01 PM, Dickson, Mike (ISS Software) < mike.dick...@hp.com> wrote: > See below for comments.. > > > > *From:* opensource-dev-boun...@lists.secondlife.com [mailto: > opensource-dev-boun...@lists.secondlife.com] *On Behalf Of *Morgaine > *Sent:* Wednesday, March 17, 2010 9:47 AM > *To:* Soft Linden > *Cc:* opensource-dev > *Subject:* [opensource-dev] Known details of LL 'Firefly' client-side > scripting > > > > Soft, I answered your post (enclosed below) quickly on Friday 12th to > correct the unfortunate misreading of the words I had written, as that was > rather urgent. I didn't have time then to answer your point about our > technical discussions with Q though, as it needed the details to be dug out. > > Now I'll deal with the specifics of the Linden client-side scripting work, > because this is where you invited "well-backed positions". Hopefully you > will see that our position is very well backed, because it is based on the > information that we were given at Linden OH. > > Morgaine, you use "our position" throughout your message. It's not clear > who you're representing when making these comments but I believe based on > past comments on the list the details are more complex than a simple binary > LL vs. everyone else. So I'd suggest you either make it clear who you're > representing with your comments or simply say "I". > > [some details removed] > > > I have indeed sat in on these, more than once, and this is why I know > enough about it to be able to make the comments I made earlier. > > I have my chat log for the OH of 3rd Feb 2010 open in front of me, just to > be sure that I am not misremembering anything. Although the discussion > contained an hour-long rejection of virtually all critical input, it was > also quite informative regarding the *general* nature of the 'Firefly' > project, so I'll summarize for you the technical details as accurately as I > can, using the original Linden words (shown in quotes) and little else. The > following was spread out over an hour: > > · "We ARE working on client-side scripting; there's a project just > getting underway. It will NOT be a 2.1 sort of thing, it's a pretty big > project." > > I understand the complexity of an effort like this but ideally I'd prefer > to see whatever approach is taken implemented in an incremental fashion. So > maybe some amount of discussion could be devoted to how to chop up the work > so it can be done in phases with feedback available after each phase. Some > of the media plug-in work was done this way in Snowglobe and I think that > approach was beneficial. > > · "My goal is to create a platform for plugin UI development with > a completely open API specification, built on an open scripting platform > (almost certainly mono)", "capable of doing anything that the viewer > protocols are capable of." > > I like this approach. The API becomes the inter-module "contract" between > modules. You can then feel free to change the underlying implementation as > long as that contract is observed for a given version of the api. > > · "The viewer that incorporates this scripting platform will be > BUILT in the scripting language." > > · "It needs to have a solid sandbox model (therefore Mono or > another robust VM) and a strong, capabilities-based security model." > > · "Each plugin should be required to request specific caps based > on need. In its metadata, it has to say what caps it's going to need. Any > attempt to request other capabilities at runtime is rejected, the VM sandbox > can control its abilities." > > · The goal is to provide "a model in which people can trust a > plugin." > > I strongly agree with this approach, especially given the goal above to > code the bulk of the app using the platform. There are lots of good > examples of how this
Re: [opensource-dev] Known details of LL 'Firefly' client-side scripting
You missed the point of my response to Soft then, Mike. Soft complained that she didn't know the details of Firefly and that *WE*(all of us here, including yourself) were not using well backed positions, and asked for details of our discussions with Q. I've now supplied the details of the only informative OH we've had on the subject, to show that what we've been discussing since February was very well founded in the information we have available to us. And that discussion was objective and technical, although limited through lack of information and response from Lindens. I agree entirely with your suggestion that this be developed incrementally in concert with the opensource-dev community, because, after all, we are going to be affected massively by it. Unfortunately it's an internal Linden project and so we will have no say on the most fundamental features of its implementation and the requirements that it fulfills --- it will be a fait accompli when it suddenly appears. And that's the problem. 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] Known details of LL 'Firefly' client-side scripting
Mike, you chose not to contribute to the threads on client-side scripting in February nor in March, until today. You really can't pin the blame on us if the positions expressed on the list to date do not reflect your own. I'm very glad to hear your views now though. We very much need an open technical discussion on this topic, because adding client-side scripting is the single most important thing that could happen to a viewer. The UI changes in Viewer 2.0 will be completely insignificant compared to what client-side scripting can achieve. Morgaine. === On Wed, Mar 17, 2010 at 4:34 PM, Mike Dickson wrote: > On 03/17/2010 11:17 AM, Morgaine wrote: > > Mike, Soft was referring to us on the opensource-dev list as a whole. > That's the "we". > > As to which "our position" is, that's simply the aggregate of what everyone > has expressed in this list. People speak for themselves here. > > That's really my point. I wrote because your response doesn't represent my > own position and I felt that I was potentially being lumped into the "our" > category. And I re-read Soft's original message and I don't see "we" or > "us" mentioned. It looked to me like he was simply stating that making > impassioned arguments that drift towards the emotional are > counter-productive and likely to get ignored. Again, that sounds pretty > reasonable to me. And very understandable. > > > If you're not sure what that "community position" is, you have a lot of > reading to do. You'll have to start back in February, in the massive thread > that was begun by this post of mine on client-side > scripting<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/88.html>. > The discussion continues, and it's totally open. > > I did in fact read the entire thread and again, I don't agree that the > "community position" is that clear cut. Certainly not as binary as you've > painted it. I saw lots of relevant points made from different positions. > My personal perspective is that I'd like to see what LL has put forward > implemented, ideally in phases and as much in the open as possible. I > accept that others may not agree with ot but I haven't personally seen an > example that *can't* be done with the LL model though ideally there'd be a > test bed to try out things as proof points either way. > > Mike > > > > > Morgaine. > > > > > > > On Wed, Mar 17, 2010 at 4:01 PM, Dickson, Mike (ISS Software) < > mike.dick...@hp.com> wrote: > >> See below for comments.. >> >> >> >> *From:* opensource-dev-boun...@lists.secondlife.com [mailto: >> opensource-dev-boun...@lists.secondlife.com] *On Behalf Of *Morgaine >> *Sent:* Wednesday, March 17, 2010 9:47 AM >> *To:* Soft Linden >> *Cc:* opensource-dev >> *Subject:* [opensource-dev] Known details of LL 'Firefly' client-side >> scripting >> >> >> >> Soft, I answered your post (enclosed below) quickly on Friday 12th to >> correct the unfortunate misreading of the words I had written, as that was >> rather urgent. I didn't have time then to answer your point about our >> technical discussions with Q though, as it needed the details to be dug out. >> >> Now I'll deal with the specifics of the Linden client-side scripting work, >> because this is where you invited "well-backed positions". Hopefully you >> will see that our position is very well backed, because it is based on the >> information that we were given at Linden OH. >> >> Morgaine, you use "our position" throughout your message. It's not clear >> who you're representing when making these comments but I believe based on >> past comments on the list the details are more complex than a simple binary >> LL vs. everyone else. So I'd suggest you either make it clear who you're >> representing with your comments or simply say "I". >> >> [some details removed] >> >> >> I have indeed sat in on these, more than once, and this is why I know >> enough about it to be able to make the comments I made earlier. >> >> I have my chat log for the OH of 3rd Feb 2010 open in front of me, just to >> be sure that I am not misremembering anything. Although the discussion >> contained an hour-long rejection of virtually all critical input, it was >> also quite informative regarding the *general* nature of the 'Firefly' >> project, so I'll summa
Re: [opensource-dev] Known details of LL 'Firefly' client-side scripting
Mike, with reference to CLR and languages (I'm trying to partition the discussion into manageable chunks, so only one topic at a time): On Wed, Mar 17, 2010 at 4:01 PM, Dickson, Mike (ISS Software) < mike.dick...@hp.com> wrote: > > Assuming a CLR based approach doesn't simply mean C# there are lots of > good scripting implementations (Lua, Python, Rubs, etc.) available as .NET > language implementations all of which should be able to be used. It's > possible that the sandbox implementation might limit that but I don't see an > obvious reason it should. Also if this list is too limiting again you can > install a module that provides a proxy to another environment implemented in > whatever language you choose. > > You're missing two key points here. The first is that reimplementing a language on top of an existing runtime is not the same thing as being able to use a language natively. Languages are implemented with specific runtimes for very good technical reasons, and shoehorning them into another framework's VM model is almost guaranteed to deny essential facilities from operating. For example, you mention Lua, which I use quite a lot. Lua is designed expressly for use in embedding and extending arbitrary applications through its C/C++ API. If Lua is re-implemented afresh on top of another CLR language, it loses that native ability entirely. Alternatively, if the existing Lua implementation in ANSI C is linked into the CLR runtime directly, then the C/C++ interface is still available but it would have to be denied as it would break the sandbox. Either way, Lua scripting would no longer benefit from the masses of add-ons available in the Lua community, virtually all of which are implemented as native extensions. A bigger issue though is simply not being language agnostic in the first place. This totally misses the opportunity of harnessing people's skills in dozens or hundreds of languages that are not available for CLR, using their favorite IDEs and other tools. It denies them the benefit of the huge number of libraries out there in other languages, representing thousands of man years of effort. Restricting the languages available for *sim-side* scripting made sense, because that's an environment that Lindens need to control. But that requirement does not apply to client-side scripting of extensions, which are about *user control and empowerment*, not LL's. If there were no other solution, then fine. But there are other solutions. Over the 2+ years of AWG, we have examined in quite some depth how to create language-agnostic interfaces (mostly with the viewer in mind), and it's not particularly hard. I've detailed one clean approach here in various posts since February -- namely, using a socket API so that any language whatsoever could use the API from an external process, with no language-specific programming nor bloat in the viewer. The benefits of doing this are colossal (I've listed them in prior threads), while the disadvantages are really minor, mostly that it takes more effort to reach bare metal speeds. Given such a language-agnostic approach, the sky is really the limit, because quite literally anything is possible in external processes written in arbitrary languages, without being imprisoned in a sandbox that has to be made leaky for interfacing and hence is necessarily compromised. All the specialist languages for concurrency or artificial intelligence or scientific simulation can be brought to bear directly. The result would be quite astounding. So there *ARE* alternatives, and they don't have the problems with the embedded Mono approach that several of us have described here over the last 4-5 weeks. Finally, your suggestion to use a proxy is just a bandaid on top of an inherent design fault, which is the hardwiring in of one scripting runtime into the viewer in the first place. It is not necessary, and it imposes too many restrictions with only an illusion of security, not to mention creating a maintenance nightmare for the viewer. If we can get client-side scripting to be discussed with Lindens openly, these pro's and con's will be brought into the light of day, and then we can see how the balance tips in terms of engineering benefits, objectively. And that's my purpose in raising the matter. Design done in secret avoids objective assessment. 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] Known details of LL 'Firefly' client-side scripting
Argent is exactly right. >From sitting in on these OHs, the intention that has come across (but with some ambiguity) is definitely that binaries will be pushed to our clients and executed, even if this involves some action in-world. Whatever the mechanism of transfer, these binaries are inherently untrusted and untrustworthy by inspection. If you choose to assign your trust to them, that is your own personal lookout. Note that this situation is *NOT* like on the Web, where Javascript is sent to browsers as *source code* which is available for inspection by anyone who cares to do it. Because of the possibility of inspection, the Web enjoys the "many eyeballs" effect that allows browsers to flag sites as malicious. There will be no such protections here, because the distributed binaries are opaque. The mere idea that opaque binaries are being sent to people and executed locally on their PCs should be enough to send shivers down everyone's spine, even if they're only minimally aware of security. From our technical and open source perspective here, which is after all what opensource-dev is all about, it's just completely unacceptable. Designing script execution to run on LL's servers is wholly within Linden rights to do in secret. Designing script execution to run *on OUR private machines* is NOT within Linden rights to do in secret at all. Morgaine. == On Wed, Mar 17, 2010 at 6:45 PM, Argent Stonecutter wrote: > On 2010-03-17, at 12:31, Dzonatas Sol wrote: > > You install a program on your computer, and you either trust it or > > you don't. It comes down to that, so it doesn't matter if it is .NET > > or Java or some binary made by company XYZZY. > > The quotes from the office hours make it seem like they're talking > about having in-world content pushing stuff onto your client, not > explicitly installing code. > > ___ > 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] Known details of LL 'Firefly' client-side scripting
[Mailmain/pipermail is slicing up posts again in the M/L archive. I'll try a repost.] Argent is exactly right. >From sitting in on these OHs, the intention that has come across (but with some ambiguity) is definitely that binaries will be pushed to our clients and executed, even if this involves some action in-world. Whatever the mechanism of transfer, these binaries are inherently untrusted and untrustworthy by inspection. If you choose to assign your trust to them, that is your own personal lookout. Note that this situation is *NOT* like on the Web, where Javascript is sent to browsers as *source code* which is available for inspection by anyone who cares to do it. Because of the possibility of inspection, the Web enjoys the "many eyeballs" effect that allows browsers to flag sites as malicious. There will be no such protections here, because the distributed binaries are opaque. The mere idea that opaque binaries are being sent to people and executed locally on their PCs should be enough to send shivers down everyone's spine, even if they're only minimally aware of security. From our technical and open source perspective here, which is after all what opensource-dev is all about, it's just completely unacceptable. Designing script execution to run on LL's servers is wholly within Linden rights to do in secret. Designing script execution to run *on OUR private machines* is NOT within Linden rights to do in secret at all. Morgaine. > > > > > > == > > > On Wed, Mar 17, 2010 at 6:45 PM, Argent Stonecutter < > secret.arg...@gmail.com> wrote: > >> On 2010-03-17, at 12:31, Dzonatas Sol wrote: >> > You install a program on your computer, and you either trust it or >> > you don't. It comes down to that, so it doesn't matter if it is .NET >> > or Java or some binary made by company XYZZY. >> >> The quotes from the office hours make it seem like they're talking >> about having in-world content pushing stuff onto your client, not >> explicitly installing code. >> >> ___ >> 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] Known details of LL 'Firefly' client-side scripting
Oh dear, I may see the problem. Mailmain/pipermail seems to be slicing posts on a leading 'From ' as if incoming posts were in Unix mailbox format (they're not!), a very elementary mistake. Any Lindens reading this, please give the mail/web sysadmins a heads-up. Meanwhile, it's just a guess, but don't start paragraphs with 'From ' folks. Morgaine. = On Wed, Mar 17, 2010 at 8:43 PM, Morgaine wrote: > [Mailmain/pipermail is slicing up posts again in the M/L archive. I'll try > a repost.] > > > > Argent is exactly right. > > From sitting in on these OHs, the intention that has come across (but with > some ambiguity) is definitely that binaries will be pushed to our clients > and executed, even if this involves some action in-world. Whatever the > mechanism of transfer, these binaries are inherently untrusted and > untrustworthy by inspection. If you choose to assign your trust to them, > that is your own personal lookout. > > Note that this situation is *NOT* like on the Web, where Javascript is > sent to browsers as *source code* which is available for inspection by > anyone who cares to do it. Because of the possibility of inspection, the > Web enjoys the "many eyeballs" effect that allows browsers to flag sites as > malicious. There will be no such protections here, because the distributed > binaries are opaque. > > The mere idea that opaque binaries are being sent to people and executed > locally on their PCs should be enough to send shivers down everyone's spine, > even if they're only minimally aware of security. From our technical and > open source perspective here, which is after all what opensource-dev is all > about, it's just completely unacceptable. > > Designing script execution to run on LL's servers is wholly within Linden > rights to do in secret. Designing script execution to run *on OUR private > machines* is NOT within Linden rights to do in secret at all. > > > Morgaine. > >> >> >> >> >> >> == >> >> >> On Wed, Mar 17, 2010 at 6:45 PM, Argent Stonecutter < >> secret.arg...@gmail.com> wrote: >> >>> On 2010-03-17, at 12:31, Dzonatas Sol wrote: >>> > You install a program on your computer, and you either trust it or >>> > you don't. It comes down to that, so it doesn't matter if it is .NET >>> > or Java or some binary made by company XYZZY. >>> >>> The quotes from the office hours make it seem like they're talking >>> about having in-world content pushing stuff onto your client, not >>> explicitly installing code. >>> >>> ___ >>> 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] Known details of LL 'Firefly' client-side scripting
[Another attempt to get the archives to see the rest of the post, prefixing 'From '.] Argent is exactly right. >From sitting in on these OHs, the intention that has come across (but with some ambiguity) is definitely that binaries will be pushed to our clients and executed, even if this involves some action in-world. Whatever the mechanism of transfer, these binaries are inherently untrusted and untrustworthy by inspection. If you choose to assign your trust to them, that is your own personal lookout. Note that this situation is *NOT* like on the Web, where Javascript is sent to browsers as *source code* which is available for inspection by anyone who cares to do it. Because of the possibility of inspection, the Web enjoys the "many eyeballs" effect that allows browsers to flag sites as malicious. There will be no such protections here, because the distributed binaries are opaque. The mere idea that opaque binaries are being sent to people and executed locally on their PCs should be enough to send shivers down everyone's spine, even if they're only minimally aware of security. From our technical and open source perspective here, which is after all what opensource-dev is all about, it's just completely unacceptable. Designing script execution to run on LL's servers is wholly within Linden rights to do in secret. Designing script execution to run *on OUR private machines* is NOT within Linden rights to do in secret at all. Morgaine. > > > > == > > > On Wed, Mar 17, 2010 at 6:45 PM, Argent Stonecutter < > secret.arg...@gmail.com> wrote: > >> On 2010-03-17, at 12:31, Dzonatas Sol wrote: >> > You install a program on your computer, and you either trust it or >> > you don't. It comes down to that, so it doesn't matter if it is .NET >> > or Java or some binary made by company XYZZY. >> >> The quotes from the office hours make it seem like they're talking >> about having in-world content pushing stuff onto your client, not >> explicitly installing code. >> >> ___ >> 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] Known details of LL 'Firefly' client-side scripting
> [Another attempt to get the archives to see the rest of the post, prefixing 'From '.] Success. Don't start your posts with 'From ' folks until it's fixed. 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 Plugin System Design
Rob, sockets do not add any bulk to a *viewer* at all, since the socket code is already present in every viewer. What's more, the suggestion of bulk doesn't even make sense in the context of directly embedding Lua in the viewer, since embedding Lua will grow the viewer by the size of the Lua interface at the very least. Lua is really small and has very simple interfacing requirements, but even so, that's infinitely more bulk than the zero additional bulk of sockets. :-) Of course, outside of the viewer, plugins implemented as external processes do carry that extra bulk, but in exchange you get an immense number of good things. Principle among them are hardware MMU-guaranteed process isolation, free harnessing of multiple cores, almost total absence of the many hard problems of concurrent multiprogramming, and total language agnosticism so that everyone is happy. The tradeoff here is completely in favor of socket-connected processes. And there are many more benefits. Rob, you may not have seen the following before, but I described in some detail the problems with Direct Language Embedding in a reply to Ricky on 8th March<https://lists.secondlife.com/pipermail/opensource-dev/2010-March/000625.html>. I recommend that you examine that email because it factors in decades of experience with the very hard problems of concurrent multiprogramming, which you are completely ignoring. A multiprogrammed system for concurrent Lua programming is a completely different beast to normal Lua embedding. I like Lua a lot. Although it would present far fewer problems than Mono in an embedded role, embedding a language runtime is still the wrong approach for this job. It would bloat the viewer, create a huge multiprogramming problem, encumber development with years of concurrency headaches (I'm not joking), and impose a large number of constraints on scripts that will effectively hobble them and annoy expert programmers just like LSL does. None of this is necessary. It's a very bad package deal, while socket-connected plugins have none of these issues. Morgaine. === On Wed, Mar 17, 2010 at 9:42 PM, Rob Nelson wrote: > As stated before, sockets add unnecessary bulk to any plugin > architecture, ESPECIALLY HTTP. The SL viewer currently takes up 100% > CPU even with scripting turned off; The last thing we need is more > memory or processor load. > > There are ways to signal the viewer when an event has occurred without > using sockets, and without running a separate process. A simple > std::queue of events being passed to the Lua engine is what I currently > use. I therefore suggest C++ Dynamic Shared Objects, each providing a > language option (Lua, Python, Mono), but with a shared interface that: > > * Provides public start/restart/kill methods (for a scripting console) > * Is in its own thread (to prevent blocking) > * provides a way to pass in events with variable arguments (Luna uses a > string stream with serialized objects) > * Provides the scripting engine some basic "environmental > variables" (Viewer name/channel/version, settings THAT ARE NOT > PASSWORDS, some other global vars like gAgent) > * Automatically starts (if configured to do so) only AFTER login to > prevent receiving login details > * Does not provide a way to create raw messages or send money. > > There's probably a bunch of other requirements, too. > > If firefly is truly using Mono, then I do sincerely hope it fails. Mono > is way too slow to run plugins efficiently, and as seeing that the > viewer is already chock-full of slowness, I don't want any more overhead > added. > > Rob Nelson > Luna Viewer > http://luna-viewer.googlecode.com/ > > On Wed, 2010-03-17 at 10:50 -0500, Argent Stonecutter wrote: > > On 2010-03-17, at 10:21, Dzonatas Sol wrote: > > > Ricky wrote: > > >> So far, barring any LL concepts, we have (as far as I know so far!) > > >> two designs of plugin system: > > >> 1: Socket-based plugins - as�suggested�by Morgaine. > > >> 2: D-Bus or similar existing IPC tool. > > >> 3: C++ Dynamically Shared Objects - my suggestion. > > > > > > 4. REST/HTTP > > > > That's just a specific design for category 1. > > > > ___ > > 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 > ___ 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] Proposal: Howto add a new feature to snowglobe.
Carlo, you're missing something very important in your write-up. The issue that you haven't covered is that Snowglobe is intended for interoperation with other worlds as well, not just with SL. Our work in VWRAP <http://www.ietf.org/mail-archive/web/ogpx/current/maillist.html> has the goal of allowing a single client to work with any virtual world that can speak the protocol, and this applies very directly to Snowglobe. Pixel has added new OGP functionality in this direction already as you know, and it is reasonable to expect that this code will be evolving further until Snowglobe speaks full VWRAP. What this means is that Snowglobe is not merely an SL viewer, but will allow any VWRAP compatible world to be visited --- Lindens themselves agree on this direction. You might like to read the article that three of us wrote recently for IEEE Internet Computing about the expected future of VWRAP, for which a Linden was co-author. The article is available at: VWRAP for Virtual Worlds Interoperability<http://internetmessagingtechnology.org/pubs/VWRAP-for-Virtual-Worlds-Interoperability-mic2010010073.pdf> . Needless to say, if virtual world travellers are to use Snowglobe in multiple VWs, then the viewer is going to have to do more than just handle the SL subset of functionality. In other words, features for working with other worlds will also be appropriate in Snowglobe. I confirmed that features for interoperability would be acceptable in Snowglobe *in principle *, back when Rob Linden was handling the Hippotropolis meetings. I assume that this is still the case, since Linden support of VWRAP remains as strong as ever. This doesn't mean that everything will go in of course, but it does mean that there will be features proposed which Linden Lab may not wish to merge back into their own SL viewer --- that would be perfectly normal. Snowglobe developers who travel in virtual worlds will undoubtedly want to have a strong say in this, and even Lindens are quite likely to want to cherry-pick among such additional features for possible inclusion in the vendor branch. After all, it's reasonable to assume that LL doesn't want its main client to be left behind once we have interoperability. So the situation is rather more flexible than you suggest. Snowglobe isn't only about working with SL, at least not until LL issues a restrictive policy which would make Snowglobe unpalatable for general VWRAP use. I see no sign of that. Just to be sure that we're all on the same page, perhaps Merov would like to reaffirm Rob's statement regarding features that support interoperability in Snowglobe? Since we don't actually have any particular features in mind at this time, it's more a general statement of principle and intent that matters at this stage. Morgaine. == On Thu, Mar 18, 2010 at 12:02 PM, Carlo Wood wrote: > Here is some food for thought: > > -- Question: Who determines what is added to the viewer and what not? > > I propose (to be decided by Lindens, not others) the following: > > There are two different categories of things that can be added > to the viewer: > > Category 1: Bug fixes; intended behavior is not as expected. > Category 2: Features; intended behavior is changed (added). > > Category 1 > -- > > These are handled the same as category 2, but without the need > to decide at the user-experience level if the patch is wanted. > Thus, for *accepted* feature AND bug fix: > > A committer writes the patch. > The patch is reviewed by other committers. > No committer can stop a patch entirely, but they can request > patches to be taken back to the drawing board based on: > > * CPU usage (FPS drop) > * Memory usage > * Coding style > * Maintainability (how easy it is to make changes without breaking it) > * Robustness (chance it breaks accidently by changes elsewhere) > > Committer are expected to work together and respect eachother, > but especially the original committer needs to be prepared to > spend another week or two to address each and every comment > made by other committers (for which the jira is used). > > When all other committers involved, with a minimum of one other > committer, are satisfied; the patch may be committed. > > Category 2 > -- > > In the case of a new feature, the new feature should really > first be discussed on this list, before being implemented. > > What is being discussed are the effects on the users, not > the technical effects like CPU usage etc. Non-committers > can (politely) provide insight and feedback, but do not > have any vote on whether or not a new feature will be added. > > In fact, nobody has a vote: in the end it's the call of > Linden Lab, where we assume that if any Linden speak
Re: [opensource-dev] Proposal: Howto add a new feature to snowglobe.
On Thu, Mar 18, 2010 at 5:30 PM, Tateru Nino wrote: > Huh. Curious. I have a client launcher (for SL among other things) called 'vwrap'. I expect that before long, the prefix 'vw' will become as fashionable as 'e' and now 'i'. ;-) Morgaine. === On Thu, Mar 18, 2010 at 5:30 PM, Tateru Nino wrote: > Huh. Curious. I have a client launcher (for SL among other things) called > 'vwrap'. > > > On 19/03/2010 4:23 AM, Morgaine wrote: > > Carlo, you're missing something very important in your write-up. > > The issue that you haven't covered is that Snowglobe is intended for > interoperation with other worlds as well, not just with SL. Our work in > VWRAP <http://www.ietf.org/mail-archive/web/ogpx/current/maillist.html>has > the goal of allowing a single client to work with any virtual world that > can speak the protocol, and this applies very directly to Snowglobe. Pixel > has added new OGP functionality in this direction already as you know, and > it is reasonable to expect that this code will be evolving further until > Snowglobe speaks full VWRAP. > > What this means is that Snowglobe is not merely an SL viewer, but will > allow any VWRAP compatible world to be visited --- Lindens themselves agree > on this direction. You might like to read the article that three of us > wrote recently for IEEE Internet Computing about the expected future of > VWRAP, for which a Linden was co-author. The article is available at: VWRAP > for Virtual Worlds > Interoperability<http://internetmessagingtechnology.org/pubs/VWRAP-for-Virtual-Worlds-Interoperability-mic2010010073.pdf> > . > > Needless to say, if virtual world travellers are to use Snowglobe in > multiple VWs, then the viewer is going to have to do more than just handle > the SL subset of functionality. In other words, features for working with > other worlds will also be appropriate in Snowglobe. I confirmed that > features for interoperability would be acceptable in Snowglobe *in > principle*, back when Rob Linden was handling the Hippotropolis meetings. > I assume that this is still the case, since Linden support of VWRAP remains > as strong as ever. > > This doesn't mean that everything will go in of course, but it does mean > that there will be features proposed which Linden Lab may not wish to merge > back into their own SL viewer --- that would be perfectly normal. Snowglobe > developers who travel in virtual worlds will undoubtedly want to have a > strong say in this, and even Lindens are quite likely to want to cherry-pick > among such additional features for possible inclusion in the vendor branch. > After all, it's reasonable to assume that LL doesn't want its main client to > be left behind once we have interoperability. > > So the situation is rather more flexible than you suggest. Snowglobe isn't > only about working with SL, at least not until LL issues a restrictive > policy which would make Snowglobe unpalatable for general VWRAP use. I see > no sign of that. > > Just to be sure that we're all on the same page, perhaps Merov would like > to reaffirm Rob's statement regarding features that support interoperability > in Snowglobe? Since we don't actually have any particular features in mind > at this time, it's more a general statement of principle and intent that > matters at this stage. > > > Morgaine. > > > > > > > > == > > On Thu, Mar 18, 2010 at 12:02 PM, Carlo Wood wrote: > >> Here is some food for thought: >> >> -- Question: Who determines what is added to the viewer and what not? >> >> I propose (to be decided by Lindens, not others) the following: >> >> There are two different categories of things that can be added >> to the viewer: >> >> Category 1: Bug fixes; intended behavior is not as expected. >> Category 2: Features; intended behavior is changed (added). >> >> Category 1 >> -- >> >> These are handled the same as category 2, but without the need >> to decide at the user-experience level if the patch is wanted. >> Thus, for *accepted* feature AND bug fix: >> >> A committer writes the patch. >> The patch is reviewed by other committers. >> No committer can stop a patch entirely, but they can request >> patches to be taken back to the drawing board based on: >> >> * CPU usage (FPS drop) >> * Memory usage >> * Coding style >> * Maintainability (how easy it is to make changes without breaking it) >> * Robustness (chance it breaks accidently by changes elsew
Re: [opensource-dev] Proposal: Howto add a new feature to snowglobe.
On Thu, Mar 18, 2010 at 5:48 PM, Carlo Wood wrote: > > If it was possible to add arbitrary extra code and/or make > arbitrary changes without that it gets harder and harder to > keep up with changes in the main viewer, then it would the > call of the open source community as much as that of LL imho. > But that is not the case. Nobody referred to "arbitrary extra code", no straw men please. ;-) Some things will be perfectly reasonable to expect in Snowglobe, agreed by patch developers and full committers to be a good thing, even when Lindens may choose not to import them back into their vendor branch (yet). As an example, it is quite easy to imagine VWRAP providing transport for Collada mesh objects that work in Opensim long before they do in SL. I expect that Snowglobe will be a leading test environment for such things. So we're not talking about "arbitrary extra code", but about perfectly reasonable features that will be required in Snowglobe if it is to be a useful viewer for VW interoperation. Morgaine. === On Thu, Mar 18, 2010 at 5:48 PM, Carlo Wood wrote: > In what respect did I miss this? > > Are you implying that it should be possible to add new features > that Linden Lab *disagrees* with? > > If not, and as you say they don't disagree with VWRAP, then I don't > see the issue. VWRAP compatibility falls in category 2, it's a new > "feature", hardly anyone here will be even interested in given > feedback because it's rather straight forward (add VWRAP compatibility > to snowglobe) and that will not change any ones user experience, apart > from adding possibilities). > > LL will say: ok go ahead, and then we can start to implement it. > > The main reason that I think that LL has the last say in what > goes into snowglobe is because they (merov? maybe it should just > be merov's call) has to keep syncing the main viewer with > snowglobe. For example, if I propose to run 'indent' on the > source code and change the indentation of every source line > then Merov will stop that 100MB patch from being committed. > It is mainly with that issue in mind that I wanted to give LL > the last say about new features. > > If it was possible to add arbitrary extra code and/or make > arbitrary changes without that it gets harder and harder to > keep up with changes in the main viewer, then it would the > call of the open source community as much as that of LL imho. > But that is not the case. > > On Thu, Mar 18, 2010 at 05:23:44PM +, Morgaine wrote: > > Carlo, you're missing something very important in your write-up. > > > > The issue that you haven't covered is that Snowglobe is intended for > > interoperation with other worlds as well, not just with SL. Our work in > VWRAP > > has the goal of allowing a single client to work with any virtual world > that > > can speak the protocol, and this applies very directly to Snowglobe. > [...] > > -- > 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] Proposal: Howto add a new feature to snowglobe.
Dzonatas, first of all, it's important to be clear that VWRAP has not yet written up anything concerning handling of objects or avatar meshes, so this post at most reflects some of the informal discussions that we've been having on the topic. Bear that in mind here. VWRAP is intended to be an interop protocol for virtual worlds. Defining the worlds or the viewers themselves is entirely outside of the scope of the VWRAP working group. Although the following is somewhat self-referential, it is perfectly correct to say that the only requirement that VWRAP will place on virtual worlds or on viewers is to be VWRAP-compatible, in other words to be able to speak the protocol. And what's more, the protocol is intended to be extensible so that it can cope with worlds and viewers evolving as the VW scene matures. This addresses your question rather indirectly. Neither object meshes nor avatar meshes are likely to be defined in VWRAP, because that would hardwire them in. Instead, VWRAP decouples as much as possible into *services*, and addresses how those services can be accessed. All digital objects are likely to be stored in services, and this includes all mesh types of course. As a result, it is very likely that VWRAP will be transparent in respect of the avatar (and object) meshes it can handle --- it will be a matter for the viewer to be able to render a particular world's avatar mesh if a world supplies it. Note that we cannot know at this time whether the evolving metaverse will standardize on particular forms of avatar, and of course we would not wish to constrain users of the protocol to the current low quality avatars either. That creates a very strong requirement for avatar agnosticism. It's worth highlighting again that by focusing on *services* we can avoid prescribing anything in this area, while being able to transport to the viewer whatever the services choose to offer. Morgaine. = On Thu, Mar 18, 2010 at 8:18 PM, Dzonatas Sol wrote: > Morgaine wrote: > >> As an example, it is quite easy to imagine VWRAP providing transport for >> Collada mesh objects that work in Opensim long before they do in SL. >> > Can we clarify this a little about the mesh. Is this the mesh in regards to > the avatar or the mesh of objects in the environment itself. > > I still have it on the chalkboard that avatars might actually use quite > drastically different models within a scene. That would assume the simulator > that encapsulates the scene doesn't dictate the limits of the model of the > avatars in the scene. > > A bit of freedom of expression for those that can handle the details. > ___ 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] Third party viewer policy: commencement date
On Sun, Mar 21, 2010 at 5:24 PM, Kent Quirk (Q Linden) wrote: > I'm emphatically not a lawyer and I don't speak for our legal team. But: > > * Legalese is a specialized language. It's not strictly English, and it's > not always amenable to "common sense" interpretation. Think of lawyers as > people who write code in an underspecified language for a buggy compiler, > and you begin to understand why legalese is the way it is. There's a lot of > law that isn't stated, but is actually implied by the context of the > existing settled law. What that means is that if you're not a lawyer, you > probably shouldn't be attempting to interpret legal documents -- especially > not for other people[cut]. If you have legal questions about the > implication of documents, you should ask a lawyer, not a mailing list. This paraphrases quite accurately as "Our lawyers can write any old nonsense and you or I cannot question it, because the language of lawyers is beyond our comprehension." If you truly believe the words you wrote (not my paraphrasing), then I'm not surprised that you are in such deep trouble with this community which is well versed in GPL license legalities. If your statement is accurate, then your lawyers are effectively out of control by anyone in the Lab who is not a lawyer. I recommend that you shed your inferiority complex with respect to lawyers, and TELL THEM what you want written, not vice versa. The tail is wagging the dog currently. Morgaine. On Sun, Mar 21, 2010 at 5:24 PM, Kent Quirk (Q Linden) wrote: > I'm emphatically not a lawyer and I don't speak for our legal team. But: > > * Legalese is a specialized language. It's not strictly English, and it's > not always amenable to "common sense" interpretation. Think of lawyers as > people who write code in an underspecified language for a buggy compiler, > and you begin to understand why legalese is the way it is. There's a lot of > law that isn't stated, but is actually implied by the context of the > existing settled law. What that means is that if you're not a lawyer, you > probably shouldn't be attempting to interpret legal documents -- especially > not for other people. Similarly, if you're not a programmer, attempting to > interpret program source code is a risky business. Programmers are > especially susceptible to trying to interpret legal documents using a normal > dictionary because they're logical thinkers. That doesn't always work. If > you have legal questions about the implication of documents, you should ask > a lawyer, not a mailing list. > > * Similarly, any comment by one of Linden's lawyers in this forum or any > other could possibly be treated as legally binding. That also goes for > Linden employees, especially those with any seniority. So you're unlikely to > get further remarks or "clarifications", except general statements that > don't address specific questions. The policy was revised based on comments > on this list and elsewhere. That's probably a pretty good indication that > Linden Lab's lawyers now think it's clear enough to state its intent and to > stand up in court if they need it to. > >Q > > On Mar 21, 2010, at 12:55 PM, Carlo Wood wrote: > > > On Sun, Mar 21, 2010 at 05:04:58PM +0100, Tayra Dagostino wrote: > >> maybe we cannot sync this isn't a restriction against development > >> based on GPL, is a restriction against ability to connect LL grid with > >> a 3rd party viewer... > > > > No it's not. If that were the case it would say "User", not "Developer". > > Also, I don't read "you will not be able to connect", I read "you will > > be liable for any damages". Quite a different thing. > > ___ > 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] Open Development project: extending avatar wearables
Nyx, it's excellent news that you're starting this open development project. Well done! There's one thing to keep in mind though, so that it doesn't come as a surprise to anyone at the Lab (no surprise to yourself of course). When development is open and many community teams are involved, some teams will implement features before other teams do. This is great, as everyone can take code from everyone else, and the net result is that individual developers do less work. Yay! Unfortunately, LL has a Contributor's Agreement, and as a result of that appalling document, everyone can take freely from LL's code while LL cannot take freely from other teams' code, BY YOUR OWN CHOICE. This means that Lindens will end up reinventing wheels and doing much more work than need be, and your viewer will lag behind that of other teams. The above situation is extremely bad for Linden Lab, and for wear and tear on your tiny robot. Before you reply with the usual hints that "Developers are powerless about policy in LL", I would offer that your *Tao of Linden* gives you the freedom to question everything and everyone in the Lab. If you wished to do so, it would allow you to highlight that the benefits of that Contrib Agreement are extremely small or non-existent, while its cost to LL and to yourself is extremely high. You have the power to make your lawyers work *for* you, rather than against you, if you wish to exercise it. Well done on taking this strong step towards open development! Morgaine. On Mon, Mar 22, 2010 at 5:45 PM, Nyx Linden wrote: > Greetings Opensource-dev! > >This tiny robot is going to be working over the next few weeks to > begin working on the next iteration of avatar features, and needs your > help! > We're hoping to continue our overhaul of how you manage your appearance. > Since we're shooting for moving towards quarterly releases, there's a > lot of work to be done! > > I'll be setting up a sub-form for collaboration and discussion of > designs, as well as working on cleaning up some initial design concepts > for how the user interface will be presented - I'll follow up on this > list with links to the documents when they're online. > > Some of the features we want to implement: > 1) A new panel to edit what is stored in your saved outfit without > creating a new one. >This will include both an inventory view and a view of your outfit > itself, so you can drag items from your inventory to your outfit without > having an extra floater open > 2) Editing of wearable items (body parts and/or clothing objects) in the > sidebar, selectable from the outfit editor > 3) Removal of the appearance floater > 4) Order-specific outfits with the ability to re-order wearables as desired > 5) Ability to wear multiple wearables of the same type (multiple shirts, > multiple jackets and yes, multiple alpha masks!). > > I look forward to working with everyone and getting a lot of feedback > throughout the development process. I'll be releasing a lot more > detailed information as I can get it formatted and out the door. There > are just a handful of things to keep in mind. > > First, this is still a featureset developed by Linden Lab, which has a > few implications. If there is a dispute, we will hold final say on what > goes into the client we ship. There will not always be perfect consensus > on every decision made, but I will try to be more transparent about what > decisions we make and why, where appropriate. Also, since the code for > this feature will be in the main second-life viewer, we do still require > a signed CLA before we can integrate your patches into our codebase. > > Second, I ask that we all do what we can to keep the discussion civil > and collaborative. The tiny robot cloning machine still isn't working > right yet, so there is only one of me and I'll make the time to > collaborate with everyone who wants to help with creating a more robust > featureset that will ship in the time we have to develop it. Posts for > ideas that we don't have the time or resource to implement, rants, or > non-constructive feedback will receive significantly less attention. > > Once the forums are up, I'll post there with details of what > infrastructure is currently in place, what our initial designs are, and > how best to give feedback. Once we get our new branch structure in > place, I'll be doing all of my checkins in the open and will be pulling > in community contributions on a regular basis. I look forward to working > with the community on this project and providing a positive examples to > encourage other internal projects to work more directl
Re: [opensource-dev] Open Development project: extending avatar wearables
On Tue, Mar 23, 2010 at 4:35 AM, Bryon Ruxton wrote: - Could you please stop putting everything into that sidebar as the only way to access stuff. You've kept wanting to make this "communicator window " before into a single un-detachable block. And despite many of use hating it and asking for you to make separate floaters, (or at least give us that option), you keep attaching everything all together again in that sidebar. This is an ill conceived approach for many of us, who are used to identify specific panels at a specific position of our choice on the screen just like . Blending it all together makes it harder in that sense. In addition to the fact that many people simply "do not like" the sidebar, there are several more technical reasons why it is a bad idea ergonomically too, such as limiting displays to only one type at a time (eg. not inventory AND friends) and only one instance at a time (e.g can't show two profiles). In addition, the continual movement and resizing shifts the 3D world in a very dizzying way, and chasing the '<<' tab across the screen breaks an elementary ergonomics rule for toggles and is very bad for accessibility, as well as extremely annoying. Given that the sidebar has so many problem and no advantages that have ever been defended, I suggest that the work should start by the sidebar advocates explaining the benefits that they see in the sidebar. Since this is an open development project, the community can weigh the advantages of the sidebar against its disadvantages, and if the advantages are lacking then the sidebar can be dropped and filed under "bad idea", or at least made optional. Although some people will probably suggest that the *real* likelihood of getting the sidebar dropped is nil, I think we should take the moral high ground here and assume that the sidebar too is subject to community feedback. Let's assume that this is an open development project in which advice from the community is considered seriously and in which engineering judgment and commonsense will prevail. What are the ergonomic / HI advantages of the sidebar? Morgaine. === On Tue, Mar 23, 2010 at 4:35 AM, Bryon Ruxton wrote: > Could you please stop putting everything into that sidebar as the only > way to access stuff. You’ve kept wanting to make this “communicator window “ > before into a single un-detachable block. And despite many of use hating it > and asking for you to make separate floaters, (or at least give us that > option), you keep attaching everything all together again in that sidebar. > This is an ill conceived approach for many of us, who are used to identify > specific panels at a specific position of our choice on the screen just like > . Blending it all together makes it harder in that sense. > > I recall LL hiring a guy who worked on the Tivo interface which is a great > one for its purpose. But the viewer is a much more complex interface. I see > too much of the Tivo formula into this “drawer”. The worse part is that the > sidebar buttons are stuck on the left side and actual move with the sidebar > panel itself. That seems wrong. Button should stay at the same place on the > right in an Adobe fashion for distinction purpose. > > I wish you had studied and adopted the approach of the Adobe UIs with > stackable and detachable panels and buttons on the right side (which always > stay there). Their approach is a much better solution in my view that this > drawer type, which is a huge waste of space right now and adding to the > required amount of clicks to get somewhere. > > In short, please reserve an option for detachable floaters as much as > possible, and please > consider the Adobe approach for a more flexible and customizable sidebar(s) > for Version 2.x.x > > Thank you > > > On 3/22/10 8:06 PM, "Nyx Linden" wrote: > > Good question! There is still a lot of detail left out of these > descriptions, but we are planning on moving the UI in the appearance editor > into the sidebar, along with creating a new outfit editor UI. You will still > see the results of the changes you are making on your avatar in-world in > real time. There will still be an "editing appearance" mode as you have now, > it will just be accompanied by a panel in the sidebar instead of a separate > floater. > > - Nyx > > On Mon, Mar 22, 2010 at 6:56 PM, Argent Stonecutter < > secret.arg...@gmail.com> wrote: > > > On 2010-03-22, at 12:45, Nyx Linden wrote: > > 1) A new panel to edit what is stored in your saved outfit without > creating a new one. >This will include both an inventory view and a view of your outfit > itself, so you can drag items from your inventory to your outfit without
Re: [opensource-dev] Third party viewer policy: commencement date
[CC Philip] Boy Lane's article is the clearest summary of the whole sorry situation so far. I hope that his very accurate analysis is handed to someone at high level in LL, because it is clear that no Lindens on this list are able or willing to engage in the matter. The lawyers behind the scenes at LL appear to be truly out of control, and uncaring of the mammoth GPL non-compliance of what they have written. I have CC'd this post to Philip Linden, because being at arm's length from the Lab nowadays, perhaps he can see more clearly than some how far the situation has deteriorated from the original vision of an open client and an ecosystem of GPL developers. Boy Lane's article is enclosed. Morgaine. = On Tue, Mar 23, 2010 at 12:34 PM, Boy Lane wrote: > I've put my summary about TVP on my blog > http://my.opera.com/boylane/blog/linden-labs-final-3rd-party-viewer-policy-tpv > > > Linden Lab's final 3rd Party Viewer Policy (TPV) > TUESDAY, 23. MARCH 2010, 19:15:03 > > A lot of things are changing, I've voiced my opinion several times, and I > want to summarize here what I think about Linden Lab's 3rd Party Viewer > Policy (TVP) that can be found here: Policy on Third-Party Viewers | > Second Life <http://secondlife.com/corporate/tpv.php> > > Under assumption of common sense LL produced guidelines that should > regulate and control the way people can connect to their service, that is > the SecondLife grid. Guidelines which would be correct under the aspect of > common sense and I believe LL came from that perspective by initially > creating that guidelines in form of the 3rd Party Viewer Policy. > > What went wrong? They gave it in the hands of JohnDoe Linden lawyers who > obviously missed the subject completley and overstepped ridiculously. But > let's get down to the roots. > > Basically there are 2 core things very wrong with it. Initially LL requires > everyone to comply to the GPL licensing. Which is fine as that sets the > context. The GPL clearly states a developer has no warranty or liability for > the code whatsover, even if that means ones viewer starts a nuclear war > against former Soviet Russia or China or both. That clause is included in > every single file of sourcecode (not the part about the Russians or Chinese > ). LL explicitely disclaims any liability themselves for the resulting world > war but then puts exactly that liability back on the shoulders of anyone > developing a viewer. > > Not only that, by complying to their TPV a developer would also accept > universal responsibility for all and everything "viewer". To be exact, as a > developer "You assume all risks, expenses, and defects of any Third-Party > Viewers that you use, develop, or distribute." A viewer does not even need > to be able or connect to SL for that. > > In this regard it does not matter if a JohnDoe Linden comments on a mailing > list or if a legally not binding FAQ tells us that this would be only for > usage by connecting to the SL grid. It is not. TPV in it's current form > says "I'm responsible (read: guilty) for using, developing or distributing > any 3rd party viewer". > > Already by simply developing I'm assuming full responsibility for > everything. I could take the official LL sources and compile and distribute > a sourcewise identical "official" viewer, without changing a single line of > code; but with all the bugs and vulnerabilities *made by LL*. Guilty by TPV. > It's really ridiculous. > > This is a clear violation of the in the first place by LL required GPL > licensing. It puts further restrictions on developers GPL explicitly > prohibits. > > Another point of concern, putting up the RL details (which is pointless as > LL has them already and require them by ToS) is required for a listing in > the viewer directory. The details of the two guinea pigs who registered > (Kirsten's, Metabolt) were promptly published for a day before someone in LL > pressed the emergency button. But that was not the first time that LL > distributed private details. > > In summary, the policy is legal-technical flawed and not acceptable by any > dev in their right mind. What it will achieve is the destruction of any > *legal* 3rd party viewer; which probably is the (by some welcomed) goal of > LL to close-source the viewer. It will not do anything to stop malicious > clients to flourish, the Neils give a shit on policies or licenses. > > The consequence is that no 3rd party developer that uses LL's GPLed sources > (including already registered KLee or famed Emerald) can produce a > legitimate viewer that is either compliant to GPL and/or violates T
Re: [opensource-dev] Third party viewer policy: commencement date
On Wed, Mar 24, 2010 at 2:57 AM, Joe Linden wrote: > > There is no "catch 22" here. No "overstepping", and no rocket science. > The terms of the GPL are clear and well understood. The arguments around > clauses 11 and 12 of the GPL are completely baseless. Here are GPLv2 clauses 11 and 12, Joe. Which arguments around these clauses are completely baseless? - NO WARRANTY - 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. - 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. The "NO WARRANTY" section of the GPL is one of the clearest and most understandable parts of the license. When software is developed under the GPL, these clauses are not optional, they are part of the license, and they are also part of the license *when those developers create viewers expressly for use in SL*. Developers who create viewers for use in SL are not second class GPL citizens. The entirety of the license applies to them too, including clause 6 about "no further restrictions" and the two "NO WARRANTY" clauses. Failure to grant SL developers the "NO WARRANTY" of clauses 11-12 means that you cannot license your software to them under GPL. It's as simple as that. Morgaine. On Wed, Mar 24, 2010 at 2:57 AM, Joe Linden wrote: > Let me take just one more crack at explaining the situation here, then I'll > let the TPV Policy document stand on it's own. > > First, the Linden Lab viewer source code is being made available to all > under the terms of the GPLv2 License. Nothing has changed that, and the > policy doesn't modify, enhance, or limit your rights or obligations under > the GPL. > > The TPV Policy is designed to set access conditions and terms for > developers and users of viewer binaries that connect to the Second Life > grid, whether produced from code licensed under the GPL or not. Note that > the definition of TPV in that document stipulates that these are viewers > that actually connect to the SL grid, not those that may be capable of it > but are never used to log in. > > If a developer of a TPV never uses it to connect to SL, there is nothing in > that document that applies to them. Period. By the same token, if that > viewer is designed and intended to be used to access the Second Life grid(s) > there are responsibilities that follow, both for users of those viewers and > for developers. > > Surely no one here is making an argument that a viewer that is designed to > transmit user passwords (encrypted or otherwise) back to the author or the > author's proxies should be allowed to the connect to the SL grid at will and > without responsibility on the part of the author? Or that Linden Lab should > just allow unbridled use of viewers that are designed to bring down > simulators through dos vectors, expressly designed to crash viewers > repeatedly, or bypass the intent and purpose of the in-world permission > system? Those aren't rhetorical questions. > > There is no "catch 22" here. No "overstepping", and no rocket science. > The terms of the GPL are clear and well understood. The arguments around > clauses 11 and 12 of the GPL are completely baseless. > > I've seen some very dramatic "exits" from the SL open source program here > in this thread by people who have never contributed. We're making a number > of changes to the practice and policy of what we will permit to connect to > our grid so we can invest in a richer conversation with the contributors who > are interested in innovating in this space with us. The decision to work >
[opensource-dev] A note on preserving "NO WARRANTY" for SL TPV developers
In this note I'll identify 3 simple scenarios in which TPV developers can retain some confidence that the "NO WARRANTY" clauses of their open licenses remain intact. This is a technical reading of GPLv2 and similar licenses which developers can verify for themselves, rather than a legal reading of the TPV which Q Linden explained was beyond our ability to understand<https://lists.secondlife.com/pipermail/opensource-dev/2010-March/001195.html> . The 1st of April is approaching rapidly, and April Fool aside, this is also the date on which the Linden TPV policy comes into effect. That policy apparently overrides the "NO WARRANTY" clauses 11 and 12 of GPLv2 *as they apply to TPV developers*, by imposing numerous conditions and liabilities upon them. It is important that developers of TPVs realize the possible personal dangers to themselves that may result from loss of "NO WARRANTY" protection, so that they can make a personal decision about TPV development on 1st April and thereafter. Boy Lane gave a well reasoned summary of the situation here<https://lists.secondlife.com/pipermail/opensource-dev/2010-March/001263.html> . To address a small part of the uncertainty created by TPV, I'll make some simple technical observations on how to preserve the "NO WARRANTY" protections of your open sources licenses if you are a TPV developer whose viewers are used in SL by others. No part of this note is legal advice (obviously), but under the assumption that law occasionally tries to be logical, it may help developers separate what is relatively certain from what is highly uncertain. *The most important point to appreciate is that LL has no power to void the "NO WARRANTY" clause on any open source license not issued by them, or issued by them prior to 1st April 2010.* This means that the following 3 developer scenarios seem quite safe from the standpoint of their "NO WARRANTY" clauses surviving any attack: - When a viewer project is licensed under BSD, Apache, MIT, GPLv3, LGPL, or any other license other than GPLv2, this is clearly not the license granted by LL and therefore its "NO WARRANTY" protections cannot be overridden by LL. LL is not the licensor in this case. - When a viewer project is an independent project licensed by the project's developers under GPLv2 but does not use any Linden source code at all, then the license (together with its "NO WARRANTY" freedom) is being offered and granted by those developers, and it is clearly not being offered and granted by LL. Consequently LL has no say over the "NO WARRANTY" protections provided in a GPLv2 license that is granted by someone else in such an independent project. LL is not the licensor in this case. - When a project creates a TPV based on Linden sources released by LL under GPLv2 prior to 1st April 2010, those sources are not encumbered by LL's TPV document, but instead are licensed under the normal terms of a valid GPLv2 *at the time that they were released*. This is because *GPL licenses are non-revocable*, and therefore the entire GPLv2 license (including its "NO WARRANTY" clauses) which was valid upon release remains valid for all eternity. As a result, TPV developers are protected by their GPLv2 "NO WARRANTY" clauses, as long as they do not use any LL sources released on or after 1st April 2010. LL is the licensor in this case, but the GPLv2 "NO WARRANTY" protection was granted to you by Linden Lab themselves prior to the TPV possibly affecting it, and that granted license cannot be revoked, ever. In the above 3 cases, LL has no means of overriding the "NO WARRANTY" protections in the respective licenses. (Read GPLv2 clauses 11-12 carefully though, because they protect you only from *certain types* of liability, not everything.) In contrast, any other TPV scenarios are highly dependent on interpretation of the ambiguous TPV document, and hence developer protection under those conditions is very uncertain. It would have to be decided in court, and I would not wish to second guess the outcome. Much caution is advised, and even these purely technical observations should be examined carefully, and followed at your own risk only if you think they are accurate. I reiterate that the above is not legal advice, but only a technical analysis given the very well known terms of the major open source licenses. The GPL is particularly strong, and it has finally received testing in court in recent years, so relying on its strength to provide "NO WARRANTY" protection for open source developers is probably a reasonable idea. On 1st April, the situation may change though. Morgaine. On Thu, Mar 25, 2010 at 6:36 AM, Ryan McDougall wrote: > I think it's pre
Re: [opensource-dev] A note on preserving "NO WARRANTY" for SL TPV developers
Thanks Maya, and Boy! I'm very glad to hear that there is still a month to go. In that case one can still live in hope that LL might reconsider and rewrite the policy into something reasonable and unambiguously GPL-compliant for SL TPV developers. There's still time. Morgaine. On Tue, Mar 30, 2010 at 5:53 AM, Boy Lane wrote: > Small correction here, according to the FAQ the commencement date of TPV > is 30 April, so one more month from now on. > > - Original Message ----- > *From:* Morgaine > *To:* opensource-dev@lists.secondlife.com > *Cc:* Boy Lane ; Ryan McDougall > *Sent:* Tuesday, March 30, 2010 10:36 AM > *Subject:* A note on preserving "NO WARRANTY" for SL TPV developers > > In this note I'll identify 3 simple scenarios in which TPV developers can > retain some confidence that the "NO WARRANTY" clauses of their open licenses > remain intact. This is a technical reading of GPLv2 and similar licenses > which developers can verify for themselves, rather than a legal reading of > the TPV which Q Linden explained was beyond our ability to > understand<https://lists.secondlife.com/pipermail/opensource-dev/2010-March/001195.html> > . > > The 1st of April is approaching rapidly, and April Fool aside, this is also > the date on which the Linden TPV policy comes into effect. > > That policy apparently overrides the "NO WARRANTY" clauses 11 and 12 of > GPLv2 *as they apply to TPV developers*, by imposing numerous conditions > and liabilities upon them. It is important that developers of TPVs realize > the possible personal dangers to themselves that may result from loss of "NO > WARRANTY" protection, so that they can make a personal decision about TPV > development on 1st April and thereafter. Boy Lane gave a well reasoned > summary > of the situation > here<https://lists.secondlife.com/pipermail/opensource-dev/2010-March/001263.html> > . > > To address a small part of the uncertainty created by TPV, I'll make some > simple technical observations on how to preserve the "NO WARRANTY" > protections of your open sources licenses if you are a TPV developer whose > viewers are used in SL by others. No part of this note is legal advice > (obviously), but under the assumption that law occasionally tries to be > logical, it may help developers separate what is relatively certain from > what is highly uncertain. > > *The most important point to appreciate is that LL has no power to void > the "NO WARRANTY" clause on any open source license not issued by them, or > issued by them prior to 1st April 2010.* > > This means that the following 3 developer scenarios seem quite safe from > the standpoint of their "NO WARRANTY" clauses surviving any attack: > > >- When a viewer project is licensed under BSD, Apache, MIT, GPLv3, >LGPL, or any other license other than GPLv2, this is clearly not the > license >granted by LL and therefore its "NO WARRANTY" protections cannot be >overridden by LL. LL is not the licensor in this case. > > >- When a viewer project is an independent project licensed by the >project's developers under GPLv2 but does not use any Linden source code at >all, then the license (together with its "NO WARRANTY" freedom) is being >offered and granted by those developers, and it is clearly not being > offered >and granted by LL. Consequently LL has no say over the "NO WARRANTY" >protections provided in a GPLv2 license that is granted by someone else in >such an independent project. LL is not the licensor in this case. > > >- When a project creates a TPV based on Linden sources released by LL >under GPLv2 prior to 1st April 2010, those sources are not encumbered by >LL's TPV document, but instead are licensed under the normal terms of a >valid GPLv2 *at the time that they were released*. This is because *GPL >licenses are non-revocable*, and therefore the entire GPLv2 license >(including its "NO WARRANTY" clauses) which was valid upon release remains >valid for all eternity. As a result, TPV developers are protected by their >GPLv2 "NO WARRANTY" clauses, as long as they do not use any LL sources >released on or after 1st April 2010. LL is the licensor in this case, but >the GPLv2 "NO WARRANTY" protection was granted to you by Linden Lab >themselves prior to the TPV possibly affecting it, and that granted license >cannot be revoked, ever. > > > In the above 3 cases, LL has no means of overriding the "NO WARRANTY" > protections in the resp
Re: [opensource-dev] A note on preserving "NO WARRANTY" for SL TPV developers
Marine, you raise a good question, but it's hard to give a reasonable answer to a "what if" question about a totally unreasonable TPV policy. :-) The fact that the TPV document places the burden of liability for LL's own bugs (and many other things) on TPV developers' shoulders despite the extremely clear "NO WARRANTY" clauses of GPLv2, combined with Linden's refusal to discuss it further, just shows how totally beyond the bounds of reason this whole thing has become. The safest approach for TPV developers is probably to find a way to avoid falling under TPV liability at all. This is achieved by any of the 3 alternatives that I listed, all of which employ the simple strategy of relying on licenses that LL cannot overturn. Unfortunately it also means not using any new code released by LL after 30th April (not 1st April as I incorrectly stated). Developers can of course look at LL's post-April code, as the GPL always allows that, but copying their code would be very dangerous since that would bring their post-TPV rules on liability into effect, and the safety of the "NO WARRANTY" clauses then becomes a matter for debate. A genuine independent re-implementation of any new Linden code would be required to retain the "NO WARRANTY" granted by a pre-TPV GPL license, the more different the better. On the positive side, that's an opportunity for making TPV code better than LL's. :-) Note that none of this addresses how TPV developers can continue to exist in SL though, since LL could ban you for not agreeing to be bound by the TPV. The only thing that this strategy provides is a reasonable chance to be protected by the "NO WARRANTY" clauses of open licenses. Just in case some TPV developers here haven't heard, Imprudence developers have made an official announcement<http://imprudenceviewer.org/2010/03/26/an-important-announcement-regarding-the-third-party-viewer-policy/>listing in detail the reasons why they have to reject the TPV policy in order to be able to continue developing the viewer. It is very well reasoned, and is required reading for TPV developers. It needed the personal sacrifice of not developing for SL but for Opensim grids instead (thus escaping the "TPV" definition), and personally using only the Linden viewers when in SL. In exchange for this, the Imprudence developers are not subject to the TPV's outrageous conditions, particularly on personal liability. Any use of Imprudence in SL is then at the user's own risk and without placing liability on the developers. It's very sad that Linden Lab forces open source teams to these lengths. It's not in the spirit of open source at all. Indeed, the terms of the TPV are quite likely to be wholly non-compliant with the GPL as applied to TPV developers developing for SL. Morgaine. On Tue, Mar 30, 2010 at 7:58 AM, Marine Kelley wrote: > Thank you for the heads up Morgaine. Correct me if I'm wrong, but if the > "no warranty" clause vanishes from the source code, then does that mean that > LL guarantees that the code of the original viewer is bug-free ? We can't > guarantee it as open source programmers if the original devs don't in the > first place, and they can't expect us to remove it ourselves afterwards, so > who is liable for the original defects if a law suit was started because of > an exploit ? > ___ 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] A note on preserving "NO WARRANTY" for SL TPV developers
Tayra, I don't think you understand how law works.
TPV developers cannot appear in a court of law and tell the judge, "Judge,
I'm not liable to this plaintiff, because Tayra Dagostino's interpretation
of the TPV says that it doesn't apply to me."
That's not how law works.
Instead, law operates by examining THE ACTUAL WORDS THAT ARE WRITTEN in a
license or agreement. And the words that are written in the TPV are the
unconscionable and out-of-control mess that has been detailed here
extensively, as opposed to the blissful mirage of your wishful thinking.
Morgaine.
=
On Tue, Mar 30, 2010 at 4:52 PM, Tayra Dagostino
wrote:
> TPV is a license to login LL grid with a 3rd party viewer, not about
> code itself
>
> --
> Sent by iPhone
>
> Il giorno 30/mar/2010, alle ore 17.31, malachi ha
> scritto:
>
> > just my 2 cents.
> >
> >
> > * Second Life Viewer Source Code
> > * The source code in this file ("Source Code") is provided by
> > Linden Lab
> > * to you under the terms of the GNU General Public License, version
> > 2.0
> > * ("GPL"), unless you have obtained a separate licensing agreement
> > * ("Other License"), formally executed by you and Linden Lab.
> > Terms of
> > * the GPL can be found in doc/GPL-license.txt in this distribution,
> > or
> > * online at
> http://secondlifegrid.net/programs/open_source/licensing/gplv2
> >
> >
> >
> > TPV policy is irrelevant. the license in which we were given the
> > code clearly states as is seen at the web URL listed above that..
> >
> >
> > Also, for each author's protection and ours, we want to make certain
> > that everyone understands that there is no warranty for this free
> > software. If the software is modified by someone else and passed on,
> > we
> > want its recipients to know that what they have is not the original,
> > so
> > that any problems introduced by others will not reflect on the
> > original
> > authors' reputations.
> >
> >
> > You may not impose any further
> > restrictions on the recipients' exercise of the rights granted herein.
> >
> >
> > so just my 2 cents but since i recieved the code under GPL there
> > isnt a
> > dang thing Linden Lab or anyone else can do to me legally for
> > created a
> > client that doesnt abide by the TPV. They lost their right to tell us
> > what we are allowed to do with the code when they used GPL.
> > ___
> > 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
>
___
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] A note on preserving "NO WARRANTY" for SL TPV developers
Tayra, your entire post is nothing but a personal statement, with not a
shred of factual justification even attempted. Not even once have you
bothered to quote the actual words written in the TPV and use them in your
analysis.
It's great to hear that you're doing forensics. Now try and apply that
professional skill here.
Morgaine.
On Wed, Mar 31, 2010 at 4:29 PM, Tayra Dagostino
wrote:
> Maybe is better read what TPV say, not what do you think LL mean with TPV
> (read and apply forensic laws on informatic is my job... maybe I can
> understand better some terms, but isn't anyway a reason to this poor
> victimistic show)
>
>
>
> GPL rights for developers aren't touched, GPL header is in each file, you
> as developer can mod, distribute and do all you want under GPL terms. This
> work for all uses you wantto do with the viewer code (limited by GPL), in
> the moment you say your viewer is for Second Life grid of Linden Labs
> Research the relationship isn't anymore from you and your software but from
> you and LL.
>
>
>
> You can write patch and mod the viewer with copybot features or other, and
> connect to JohnSmith Research LtD SuperLife grid, nobody say else, but if
> you want your viewer is listed in viewer Ll directory and allowed to connect
> to Second Life grid GPL is out of field, the "rules" are TPV (as for
> resident the rules are CS and TOS). All warranty listed in TPV are binded to
> developer modification, is obvious if a bug is pre-existent is out of
> developer range (a developer have responsibility only about what he/she
> write, is more than easy ask compensation if a developer is charged for a
> bug previously written by LL initial source code)
>
>
>
> Developer right are protected by GPL itself, nobody, neither LL, can touch
> it, TPV is a suite of rules between YOU and Linden. LL itself cannotmodify
> GPL license, TPV is only binded in relationship from LL and developers than
> distribute or patch or mod something called "viewer for LL second life grid"
> (no software neither GPL involvement).
>
>
>
> You can blame about TPV only if you are going to mod the code with bad
> features
>
>
>
> Is better for all stop this victim roleplay, if you think something isn't
> so clear you can ask to clarify, but TPV is totally stranger from GPL, merge
> with perosnal fantasy what not understanded isn't good for nobody.
>
>
>
> Sorry for typo but iPhone keypad isn’t easy to use for long email ;)
>
> --
> Sent by iPhone
>
> Il giorno 31/mar/2010, alle ore 16.46, Morgaine <
> morgaine.din...@googlemail.com> ha scritto:
>
> Tayra, I don't think you understand how law works.
>
> TPV developers cannot appear in a court of law and tell the judge, "Judge,
> I'm not liable to this plaintiff, because Tayra Dagostino's interpretation
> of the TPV says that it doesn't apply to me."
>
> That's not how law works.
>
> Instead, law operates by examining THE ACTUAL WORDS THAT ARE WRITTEN in a
> license or agreement. And the words that are written in the TPV are the
> unconscionable and out-of-control mess that has been detailed here
> extensively, as opposed to the blissful mirage of your wishful thinking.
>
>
> Morgaine.
>
>
>
>
>
> =
>
> On Tue, Mar 30, 2010 at 4:52 PM, Tayra Dagostino <
> tayra.dagost...@gmail.com> wrote:
>
>> TPV is a license to login LL grid with a 3rd party viewer, not about
>> code itself
>>
>> --
>> Sent by iPhone
>>
>> Il giorno 30/mar/2010, alle ore 17.31, malachi <
>> mala...@tamzap.com> ha
>> scritto:
>>
>> > just my 2 cents.
>> >
>> >
>> > * Second Life Viewer Source Code
>> > * The source code in this file ("Source Code") is provided by
>> > Linden Lab
>> > * to you under the terms of the GNU General Public License, version
>> > 2.0
>> > * ("GPL"), unless you have obtained a separate licensing agreement
>> > * ("Other License"), formally executed by you and Linden Lab.
>> > Terms of
>> > * the GPL can be found in doc/GPL-license.txt in this distribution,
>> > or
>> > * online at
>> <http://secondlifegrid.net/programs/open_source/licensing/gplv2>
>> http://secondlifegrid.net/programs/open_source/licensing/gplv2
>> >
>> >
>> >
>> > TPV policy is irrelevant. the license in which we were given the
>> > code clearly states as is seen at the web URL listed above that...
[opensource-dev] Can you legally agree to incomprehensible conditions?
On 21st March, Q Linden explained to us<https://lists.secondlife.com/pipermail/opensource-dev/2010-March/001195.html>that legalese is not a language amenable to "common sense" interpretation, and more specifically, that programmers like ourselves should not expect to understand this Linden TPV policy document using our normal logic and our normal dictionary. I'll repeat his words here for clarity: *Kent Quirk (Q Linden)* q at lindenlab.com *Sun Mar 21 10:24:13 PDT 2010* - I'm emphatically not a lawyer and I don't speak for our legal team. But: - Legalese is a specialized language. It's not strictly English, and it's not always amenable to "common sense" interpretation. Think of lawyers as people who write code in an underspecified language for a buggy compiler, and you begin to understand why legalese is the way it is. There's a lot of law that isn't stated, but is actually implied by the context of the existing settled law. What that means is that if you're not a lawyer, you probably shouldn't be attempting to interpret legal documents -- especially not for other people. Similarly, if you're not a programmer, attempting to interpret program source code is a risky business. Programmers are especially susceptible to trying to interpret legal documents using a normal dictionary because they're logical thinkers. That doesn't always work. If you have legal questions about the implication of documents, you should ask a lawyer, not a mailing list. - Similarly, any comment by one of Linden's lawyers in this forum or any other could possibly be treated as legally binding. That also goes for Linden employees, especially those with any seniority. So you're unlikely to get further remarks or "clarifications", except general statements that don't address specific questions. The policy was revised based on comments on this list and elsewhere. That's probably a pretty good indication that Linden Lab's lawyers now think it's clear enough to state its intent and to stand up in court if they need it to. - Q I've been thinking about this extraordinary post and its relationship to our ongoing saga about the TPV, and I fail to see how any rational person could agree to something unknown, except under duress. Is it even legal to be required to agree to the incomprehensible? Does anyone know how the law works in this area? The GPL license was written by FSF lawyers specifically to be understood by programmers, so it's no surprise that the large majority of people here understand it. Given that Lindens claim that they are issuing a valid GPL license, perhaps one might accept that at face value, and assume that GPLv2 clauses 6, 7, 11 and 12 remain intact and valid. Therefore there are no "further restrictions" imposed on SL TPV developers (clause 6), and the "NO WARRANTY" clause (11-12) continues to protect developers from downstream liability, and no "conditions are imposed on you that contradict the conditions of this License" thus making the license valid (clause 7). Given the forgoing, the officially incomprehensible TPV document then no longer matters to SL TPV developers, because their rights and freedoms and lack of liability are determined entirely by the GPL. (It could be no other way anyway, since we are told that we cannot understand the TPV.) That leaves only the matter of *users* of TPVs behaving responsibly when they use TPV clients in SL, with which I'm sure every person on this list is happy to agree. (Note that developers become *users* when they connect to SL, and are bound by the same requirements as users.) When users do something bad with a TPV client, or indeed with a Linden client, then naturally they are personally responsible for their actions. In the absence of a TPV document that we can comprehend, perhaps this is the best that TPV developers can do, since agreeing to incomprehensible conditions is not something that any sensible person should consider. 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] SNOW-375 Binary Package Available
That sounds pretty interesting, Dzonatas. What is your viewer called, this TPV derived from Snowglobe with an extra patch? Morgaine. = On Sat, Apr 3, 2010 at 6:43 PM, Dzonatas Sol wrote: > This is a build of Snowglobe with SNOW-375 patch applied. This patch > provides a HTTP/REST interface to control and automate the Snowglobe > viewer. Client-side scripts and programs can then add features like > accessibility functions, automated regression tests, detached editors, > separate chat windows, inventory organizers, and more. > > Linux: > http://mono.dzonux.net/file/Snowglobe375/Snowglobe-i686-1.4-375.tar.bz2 > < > http://viewerdirectory.secondlife.com/listing/download/137/3/binary/aHR0cDovL21vbm8uZHpvbnV4Lm5ldC9maWxlL1Nub3dnbG9iZTM3NS9Tbm93Z2xvYmUtaTY4Ni0xLjQtMzc1LnRhci5iejI%3D > > > > Source: http://gitweb.dzonux.net/?p=snowglobe-1.4-375.git > < > http://viewerdirectory.secondlife.com/listing/download/137/3/source/aHR0cDovL2dpdHdlYi5kem9udXgubmV0Lz9wPXNub3dnbG9iZS0xLjQtMzc1LmdpdA%3D%3D > > > > See Also: https://jira.secondlife.com/browse/SNOW-375 > > > > You can experience how such an HTTP/REST interface performs with > Icesphere, which was the project formerly known as MonoVida Studio and > MonoVida Communicator.Icesphere interfaces with Snowglobe-375 to present > detached communications and client-side scripting via C#/Mono/.NET. > > http://mono.dzonux.net/file/Snowglobe375/communicator.zip > > Note: name change not due to pun on grid monkeys =) > > > ___ > 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] SNOW-375 Binary Package Available
Nope, client-side scripting and an HTTP/REST server are not in Snowglobe. Your patch SNOW-375 when applied to Snowglobe sources created a derived work from Snowglobe. The derived viewer is clearly a TPV. This is why I am asking you what this new TPV is called, since it is not Snowglobe but only based on it. Morgaine. === On Mon, Apr 5, 2010 at 1:42 PM, Dzonatas Sol wrote: > Has client-side scripting and an HTTP/REST server been offered in Snowglobe > before patch SNOW-375? I'm not sure how you are able to determine such > features as "derived" from Snowglobe. > > > The SNOW-375 patch > Morgaine wrote: > >> That sounds pretty interesting, Dzonatas. >> >> What is your viewer called, this TPV derived from Snowglobe with an extra >> patch? >> >> >> Morgaine. >> >> >> >> >> >> = >> >> On Sat, Apr 3, 2010 at 6:43 PM, Dzonatas Sol > dzona...@gmail.com>> wrote: >> >>This is a build of Snowglobe with SNOW-375 patch applied. This patch >>provides a HTTP/REST interface to control and automate the Snowglobe >>viewer. Client-side scripts and programs can then add features like >>accessibility functions, automated regression tests, detached editors, >>separate chat windows, inventory organizers, and more. >> >>Linux: >> >> http://mono.dzonux.net/file/Snowglobe375/Snowglobe-i686-1.4-375.tar.bz2 >>< >> http://viewerdirectory.secondlife.com/listing/download/137/3/binary/aHR0cDovL21vbm8uZHpvbnV4Lm5ldC9maWxlL1Nub3dnbG9iZTM3NS9Tbm93Z2xvYmUtaTY4Ni0xLjQtMzc1LnRhci5iejI%3D >> > >> >>Source: http://gitweb.dzonux.net/?p=snowglobe-1.4-375.git >>< >> http://viewerdirectory.secondlife.com/listing/download/137/3/source/aHR0cDovL2dpdHdlYi5kem9udXgubmV0Lz9wPXNub3dnbG9iZS0xLjQtMzc1LmdpdA%3D%3D >> > >> >>See Also: https://jira.secondlife.com/browse/SNOW-375 >> >> >> >>You can experience how such an HTTP/REST interface performs with >>Icesphere, which was the project formerly known as MonoVida Studio and >>MonoVida Communicator.Icesphere interfaces with Snowglobe-375 to >>present >>detached communications and client-side scripting via C#/Mono/.NET. >> >>http://mono.dzonux.net/file/Snowglobe375/communicator.zip >> >>Note: name change not due to pun on grid monkeys =) >> >> >>___ >>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] SNOW-375 Binary Package Available
While that may be his intention, you can't make a new Snowglobe by placing a patch in Jira, applying the patch to Snowglobe sources, and then distributing the resulting viewer as if it were a new version of Snowglobe, exempt from being a TPV. If that were possible then everyone would do likewise with their own patches in order not to be caught by the TPV policy. So until SNOW-375 is committed into Snowglobe, Dzon is releasing a new viewer that is not Snowglobe, and it's clearly a TPV so it needs a name, which is why I asked what that name was. I expect that Linden Lab would not take kindly to such TPV clients derived from Snowglobe being called "Snowglobe-XXX" as a way of bypassing the TPV policy. Perhaps Merov could comment. Morgaine. = On Mon, Apr 5, 2010 at 6:57 PM, Michael Dickson wrote: > Actually his intention could be to contribute the patches *to* snowglobe > in which case it's not a new TPV and a very reasonable example of > cooperation with a company sponsored open source project. > > That's actually very likely his intention since the patches *ARE* > SNOW-375 and not MY_TPV-375 or somesuch. > > Mike > > On Mon, 2010-04-05 at 17:41 +, Morgaine wrote: > > Nope, client-side scripting and an HTTP/REST server are not in > > Snowglobe. Your patch SNOW-375 when applied to Snowglobe sources > > created a derived work from Snowglobe. The derived viewer is clearly > > a TPV. > > > > This is why I am asking you what this new TPV is called, since it is > > not Snowglobe but only based on it. > > > > > > Morgaine. > > > > > > > > > > > > === > > > > On Mon, Apr 5, 2010 at 1:42 PM, Dzonatas Sol > > wrote: > > Has client-side scripting and an HTTP/REST server been offered > > in Snowglobe before patch SNOW-375? I'm not sure how you are > > able to determine such features as "derived" from Snowglobe. > > > > > > The SNOW-375 patch > > Morgaine wrote: > > That sounds pretty interesting, Dzonatas. > > > > What is your viewer called, this TPV derived from > > Snowglobe with an extra patch? > > > > > > Morgaine. > > > > > > > > > > > > = > > > > > > On Sat, Apr 3, 2010 at 6:43 PM, Dzonatas Sol > > mailto:dzona...@gmail.com>> > > wrote: > > > >This is a build of Snowglobe with SNOW-375 patch > > applied. This patch > >provides a HTTP/REST interface to control and > > automate the Snowglobe > >viewer. Client-side scripts and programs can then > > add features like > >accessibility functions, automated regression > > tests, detached editors, > >separate chat windows, inventory organizers, and > > more. > > > >Linux: > > > > > http://mono.dzonux.net/file/Snowglobe375/Snowglobe-i686-1.4-375.tar.bz2 > > > > < > http://viewerdirectory.secondlife.com/listing/download/137/3/binary/aHR0cDovL21vbm8uZHpvbnV4Lm5ldC9maWxlL1Nub3dnbG9iZTM3NS9Tbm93Z2xvYmUtaTY4Ni0xLjQtMzc1LnRhci5iejI%3D > > > > > >Source: > > http://gitweb.dzonux.net/?p=snowglobe-1.4-375.git > > > > < > http://viewerdirectory.secondlife.com/listing/download/137/3/source/aHR0cDovL2dpdHdlYi5kem9udXgubmV0Lz9wPXNub3dnbG9iZS0xLjQtMzc1LmdpdA%3D%3D > > > > > >See Also: > > https://jira.secondlife.com/browse/SNOW-375 > > > > > > > >You can experience how such an HTTP/REST interface > > performs with > >Icesphere, which was the project formerly known as > > MonoVida Studio and > >MonoVida Communicator.Icesphere interfaces with > > Snowglobe-375 to > >present > >detached communications and client-side scripting > > via C#/Mono/.NET. > > > > > > > http://mono.dzonux.net/file/Snowglobe375/communicator.zip > > > >Note: name change not due to pun on grid monkeys =) > >
Re: [opensource-dev] SNOW-375 Binary Package Available
Dzonatas, I still want to know what your TPV is called, to assist our discussion. You are distributing a TPV made by patching Snowglobe sources with the SNOW-375 patch. The archive you are distributing unpacks as "Snowglobe-i686-1.4.0.0", but I rather doubt that you have permission to be distributing a viewer by that name. Seeing as Lindens have stopped even the word "Life" being used in viewer names, it seems probable that they will stop the word "Snowglobe" being used by others as well. We need to know. But we won't know until Merov or some other Linden tells us. Morgaine. == On Mon, Apr 5, 2010 at 8:30 PM, Dzonatas Sol wrote: > Please note from the jira: "The purpose of this jira is to help further the > process to bring the patch to release quality." At that time, it may be > desirable to commit it to Snowglobe. Until then, the patch is offered for > community development (not as some conspiracy theory to bypass TPV). > > If you would like to vote or comment on the patch, please do so here: > https://jira.secondlife.com/browse/SNOW-375 > > Morgaine, can you keep this thread to discussion about "SNOW-375". Joe > Linden already made a specific request (in AWG chat) in response to TPV > clarification, so if you have issues with the TPV then this thread is not > the place to fulfill his request. > > Morgaine wrote: > >> While that may be his intention, you can't make a new Snowglobe by placing >> a patch in Jira, applying the patch to Snowglobe sources, and then >> distributing the resulting viewer as if it were a new version of Snowglobe, >> exempt from being a TPV. >> >> If that were possible then everyone would do likewise with their own >> patches in order not to be caught by the TPV policy. >> >> So until SNOW-375 is committed into Snowglobe, Dzon is releasing a new >> viewer that is not Snowglobe, and it's clearly a TPV so it needs a name, >> which is why I asked what that name was. >> >> I expect that Linden Lab would not take kindly to such TPV clients derived >> from Snowglobe being called "Snowglobe-XXX" as a way of bypassing the TPV >> policy.� Perhaps Merov could comment. >> >> >> Morgaine. >> >> >> >> >> >> = >> >> On Mon, Apr 5, 2010 at 6:57 PM, Michael Dickson > mike.dick...@hp.com>> wrote: >> >>Actually his intention could be to contribute the patches *to* >>snowglobe >>in which case it's not a new TPV and a very reasonable example of >>cooperation with a company sponsored open source project. >> >>That's actually very likely his intention since the patches *ARE* >>SNOW-375 and not MY_TPV-375 or somesuch. >> >>Mike >> >>On Mon, 2010-04-05 at 17:41 +, Morgaine wrote: >>> Nope, client-side scripting and an HTTP/REST server are not in >>> Snowglobe. �Your patch SNOW-375 when applied to Snowglobe sources >>> created a derived work from Snowglobe. �The derived viewer is >>clearly >>> a TPV. >>> >>> This is why I am asking you what this new TPV is called, since it is >>> not Snowglobe but only based on it. >>> >>> >>> Morgaine. >>> >>> >> > >>> >>> >>> === >>> >>> On Mon, Apr 5, 2010 at 1:42 PM, Dzonatas Sol ><mailto:dzona...@gmail.com>> >>> wrote: >>> � � � � Has client-side scripting and an HTTP/REST server been >> >>offered >>> � � � � in Snowglobe before patch SNOW-375? I'm not sure how you are >>> � � � � able to determine such features as "derived" from Snowglobe. >>> >>> >>> � � � � The SNOW-375 patch >>> � � � � Morgaine wrote: >>> � � � � � � � � That sounds pretty interesting, Dzonatas. >>> >>> � � � � � � � � What is your viewer called, this TPV derived from >>> � � � � � � � � Snowglobe with an extra patch? >>> >>> >>> � � � � � � � � Morgaine. >>> >>> >>> >>> >>> >>> � � � � � � � � = >>> >>> >>> � � � � � � � � On Sat, Apr 3, 2010 at 6:43 PM, Dzonatas Sol >>> � � � � � � � � mailto:dzona...@gmail.com> >><mailto:dzona...@gm
Re: [opensource-dev] SNOW-375 Binary Package Available
Thanks Merov! That cleared up a lot of confusion. Could you please check the word "*and*" in your following paragraph? On Tue, Apr 6, 2010 at 5:56 AM, Philippe (Merov) Bossut wrote: > > - Distributing Binaries: That indeed creates a TPV and TPV Policy will > apply if the viewer plans to connect to the SL grid *and* be listed in the > viewer directory. > > The TPV doc says that it applies to all third party clients that connect to SL, whether or not they are listed in the TPV directory. Your word "*and*" (if used as programmers use it) would mean that both conditions need to be true, which is probably not what you meant. If both conditions need to be true then any viewer not listed in the directory would be exempt from the TPV, which I believe was not your intention. (The word "plan" is also not used in the TPV.) A small clarification of that would be very useful, since it would have a major impact. Morgaine. = On Tue, Apr 6, 2010 at 5:56 AM, Philippe (Merov) Bossut wrote: > Hi, > > On Mon, Apr 5, 2010 at 11:17 AM, Morgaine > wrote: > >> While that may be his intention, you can't make a new Snowglobe by placing >> a patch in Jira, applying the patch to Snowglobe sources, and then >> distributing the resulting viewer as if it were a new version of Snowglobe, >> exempt from being a TPV. >> >> If that were possible then everyone would do likewise with their own >> patches in order not to be caught by the TPV policy. >> >> So until SNOW-375 is committed into Snowglobe, Dzon is releasing a new >> viewer that is not Snowglobe, and it's clearly a TPV so it needs a name, >> which is why I asked what that name was. >> >> I expect that Linden Lab would not take kindly to such TPV clients derived >> from Snowglobe being called "Snowglobe-XXX" as a way of bypassing the TPV >> policy. Perhaps Merov could comment. >> >> > I'll try to answer that case to the best of my understanding: > > - Commit of SNOW-375 in Snowglobe: This is a big patch and, since we don't > have a CLA for Dzonatas on file, it can't be integrated as long as that's > not cleared. Note that, to the best of my knowledge, such CLA are asked for > contributions to most FLOSS projects. In the meantime, anyone can certainly > apply Dzon's patch and build a viewer. As long as you do it for yourself, > there's no problem with this. > > - Distributing Binaries: That indeed creates a TPV and TPV Policy will > apply if the viewer plans to connect to the SL grid and be listed in the > viewer directory. > > - Snowglobe Trademark: This is still an on going issue. In > https://jira.secondlife.com/browse/SNOW-153, Robla added the following > comment: > """ > We still plan to protect this logo under trademark law. We haven't > announced a specific policy around this, but we're looking at the Fedora and > Firefox logos for examples of the tradeoffs. We don't want to have is > someone offering a trojan-horse laden viewer under the Snowglobe name > bearing this logo, and we want to make sure we've got the legal right to > stop that activity. > """ > I don't have details on where we stand legally on the trademark application > right now. In the meantime, using "Snowglobe-XXX" is unlikely to raise > issues. Using something really different though is likely safer. Which > brings us to... > > - Easy Packaging of TPV : This is actually the objective of the proposed > "BINDIST --- easy way to produce legally distributable binary packages" > https://jira.secondlife.com/browse/SNOW-495 : I've been working on this in > the background and plan to get something together shortly. I already > identified all applicable patches so I'm not too far off producing a script > doing this. > > Cheers, > - Merov > > ___ > 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
