Re: [opensource-dev] Third party viewer policy

[Ambroff Linden]

On Tue, Feb 23, 2010 at 12:37 PM, Robin Cornelius  wrote:

> On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden  wrote:
> > Mike's correct.
> >
> > If you see any wording that's ambiguous about that, let us know.
> > ___
>
>
> Well you seem to have spelled the end of my debian/ubuntu project, I
> can not meet the tems of the third party viewer policy:-
>
> "On your software download page or in another location that a user
> must visit before installing the Third-Party Viewer, you must disclose
> the following:"
>
> I cannot do this with an apt-repository, the user can bypass every
> possible webpage or description field. and the fact the policy says
> this is a MUST. The only possible way to do this is to create a custom
> program that displays a screen during the install hook of the package
> and aborts the package install. This can no longer be accepted in to
> the main debian or ubuntu repositories.
>

You can certainly do this using debconf, see the source for the
sun-java6-bin[1] package in 9.10 for an example. That package uses debconf
to present localized and frontend agnostic dialogs to prompt the user to
accept a special license. This is the same technique used by exim, postfix,
mysql-server, and loads of other packages to accept user input during
installation to perform some configuration tasks.

http://www.fifi.org/doc/debconf-doc/tutorial.html

-Ambroff

[1] Relevant code is in sun-java5-1.5.0-14/debian/JB-jdk.preinst.in
___
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 Linden]

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 
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
___
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 Linden]

On Thu, Mar 4, 2010 at 6:26 PM, Morgaine wrote:

> Ambroff, adding a specialized interface just to support an IDE is a very
> bad idea.


I think in general you are right, I was mostly just throwing it out as a
half-baked thought. You still have to build a sane object model in the
viewer before a plugin system makes much sense at all though, and whether
that object model is exposed via a plugin system or D-Bus[1] doesn't seem to
make much of a difference. They aren't that much different in terms of
effort.

This is why we were discussing generic client-side scripting here last
> month, both for viewer extensions and for world 
> enhancement.
> 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 
> Clientconcept,
>  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 
> systemthat
>  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  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.
>

Interesting, I'll have to catch up on this. At a high level parts of the
language-agnostic plugin system appears to be very similar to D-Bus, which
is already very mature and is sort of cross-platform[2]. Did you evaluate
existing IPC systems before designing this one?

-Ambroff

[1] Or whatever the Windows or Mac OS equivilant are.
[2] I think the Windows support is pretty Immature.
___
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] Moving forward with open development

[Ambroff Linden]

On Sun, Mar 21, 2010 at 9:37 AM, Gareth Nelson wrote:

> > - If you are going to contribute to Snowglobe, you will need to complete
> > the Second Life Viewer Contribution Agreement. While not everyone is
> > comfortable with it, we need to do it to protect our business interests.
> It
> > also protects you. I'll draft off of Sun's FAQ and this FSF page on the
> > topic.
>
> Bad example linking to the FSF page - the FSF don't produce
> proprietary forks (OnRez anyone?) and only ask for copyright
> assignment in order to aid enforcement of the license. As a registered
> charitable organisation, they would be forbidden legally from doing
> what LL did with OnRez.


I don't know if this is true or not, but regardless, copyright assignment
helps Linden enforce the GPL, which is good for everyone. That's why the FSF
was also used as an example.

-Ambroff
___
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