[opensource-dev] Consensus? was: Client-side scripting in Snowglobe
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
Re: [opensource-dev] Client-side scripting in Snowglobe
It is really sad. When people in the open source community have dedicated there life to help build open source products for the viewer suddenly find out that Linden Lab has totally ignored all that work already put into projects done by the open source community. Consider that I have personally logged the idea of client-side scripting back in April 2007: http://jira.secondlife.com/browse/SVC-98 I find it hard to believe that LL wouldn't want to work with anybody that has done such work. Since I don't want to believe that, then what conclusion can we come to if LL continues to leave us out in the cold. It appears as if LL takes the ideas under their wing, but only the idea. When will LL also take up those that obviously have the idea and have already spent a lot of time invested in this that would be a solid benefit to LL to have them on the team. For LL to completely do it from scratch without the others means even a greater cost to the investors of LL. It means LL employees has to spends the hours of time to comes up with the exact same design conclusions that we have come up with already. Obviously our attempt to join the team at LL isn't anything about being not productive, we just think it saves the investors money on productivity we've already done. I would like to contact the investors of Linden Lab and ask them personally their decision on the matter. Dz 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 resources to be >> accessed, as a security measure. This is fine and important >> when scripts are being downloaded from
Re: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe
Look good to me. As you said, a scripting engine (or three) could be written as a plugin. Then we'd only have to decide which plugin(s) get shipped with the client by default. A much more fruitful discussion I think. Ricky Cron Stardust On Sunday, February 21, 2010, 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
On Sun, Feb 21, 2010 at 11:29 AM, Ricky wrote: > Look good to me. As you said, a scripting engine (or three) could be > written as a plugin. Then we'd only have to decide which plugin(s) > get shipped with the client by default. And a well-written JSR-223 plug-in could give you all the JSR-223 Java scripting languages in one shot. ___ 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
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
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. There would be infinite possibilities of any location on the surface that could be tangent coordinated. If that is true, which gave the possibility of infinite surface, then one could also put another perfect sphere nearby the first perfect sphere. Here is the beauty of this, if the first perfect sphere has an infinite surface and the second perfect sphere has an infinite surface, then they are both the same infinite surface. The rules of this game never specified where to put the next perfect sphere. Now if left some space in between the two spheres, then it should still be "Even" number of moves if we continue with this one. What we put the sphere tangent or in union with the first one. It's the same surface, and the game was about the surface. If it is plainly tangent, then there would be one less coin to put on the surface, and it would be "Odd." No? Not convinced, yet? You say that would be two less coins? And you claim "Even?" Let's add another perfect sphere... Same infinite surface. When do we stop? ___ 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. There would be infinite > possibilities of any location on the surface that could be tangent > coordinated. > > If that is true, which gave the possibility of infinite surface, then one > could also put another perfect sphere nearby the first perfect sphere. > > Here is the beauty of this, if the first perfect sphere has
Re: [opensource-dev] Second Life Package Repo
I've been maintaining a gentoo overlay. Just got done doing some updates to it now. While there is a secondlife client in portage, it lacks voice support on 64-bit systems, spacenav joystick support, etc. I managed to re-verce engineer LL build process on my own and develop a much better ebuild. While its is more complex, its has full voice/spacenav support and is actually more flexible then the one supplied by portage. Because I've been doing this, I submitted several patches to fix the builds of problems that I have encountered. --Techwolf Lupindo gentoo.techwolf.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
