[opensource-dev] AW Groupies meeting tomorrow on mesh asset interop format

[Lawson English]

The AW Groupies meeting tomorrow will be Aaron Walsh talking (in voice 
with questions taken in voice and text) about the iED OpenFile Format: 
http://mediagrid.org/news/2010-11_iED_Create_Once_Experience_Everywhere.html
at http://maps.secondlife.com/secondlife/ThorneBridgeTown/156/130/22 at 
9:30 AM Second Life Time
IM Saijanai  Kuhn for an invite to AW Groupies  if you want to participate.


Lawson (Saijanai Kuhn in Second Life)
___
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] Mmeting today... was: Re: AW Groupies meeting tomorrow on mesh asset interop format

[Lawson English]

Today's AWG meeting at 9:30 AM pacific coast time will be streamed live 
to:  http://www.metanomics.net/community_forum  topic will be an open 
file format for mesh distribution between various virtual worlds
___
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] AW Groupies meeting today 9:30 AM SLT

[Lawson English]

AW Groupies meeting today, 9:30 AM Pacific Coast Time. Maccus 
McCullough,  Science and Technology Manager
Virtual World Strategic Applications US Army Simulation & Training 
Technology Center, will be our  speaker today
___
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] Transcript of Tuesday's AWG meeting (very interesting and informative)

[Lawson English]

Today's meeting was with Maccus McCullough, Science and Technology Manager
Virtual World Strategic Applications
US Army Simulation & Training Technology Center

Transcript of meeting:

http://wiki.secondlife.com/wiki/AW_Groupies/Chat_Logs/AWGroupies-2011-02-08
___
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] Progress with squeak to SL media plugin (hooray)

[Lawson English]

So, now I can render OpenGL using squeak smalltalk,and do a glCopyPixels 
to a shared memory buffer ala the SL media plugin's.

Benchmark 1000 1000x1000x4 byte glcopypixels in ~6 seconds, or roughly 
160 FPS


So a peer to peer plugin for a smalltalk (or other graphics) app could 
send data from plugin to plugin and get full native OS speed without the 
overhead of VNC.

Realtime whiteboards with no delay. Stream the graphics to the audience 
via a normal html on a prim QT movie, and you have the best of both 
worlds: realtime collab between avatars, and unlimited numbers in the 
audience.


With different aspects of SL exposed to such a plugin, you could have 
collaborative puppeteering and such, as well.


Next up: drawing from Squeak to SL plugin tester. Then p2p between 2 
people using the SL plugin tester. Etc.




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

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

[Lawson English]

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

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


Lawson


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

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

[Lawson English]

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

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


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



Lawson


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

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

[Lawson English]

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

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

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

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

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

Lawson













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

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

[Lawson English]

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


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

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

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


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



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

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



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

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



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

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

[Lawson English]

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

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

;-)


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

Lawson



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

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

[Lawson English]

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

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

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

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


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


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

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


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

Lawson





Lawson











Lawson

















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

Re: [opensource-dev] Third party viewer policy

[Lawson English]

Vex Streeter wrote:
> Soft Linden wrote:
>> On Tue, Feb 23, 2010 at 2:21 PM, Mike Dickson  wrote:
>>   
>>> On 02/23/2010 02:16 PM, Gigs wrote:
>>> 
 http://secondlife.com/corporate/tpv.php

 You all realize this is massively incompatible with the GPL, right?

   
>>> Not at all.  They're not restricting access to the code. They're
>>> restricting access to their service. And defining the terms under which
>>> that service is provided.
>>> 
>>
>> Mike's correct.
>>
>> If you see any wording that's ambiguous about that, let us know.
>>   
> Section 1c unambiguously imposes a GPL-incompatible download and/or 
> installation requirement that is unrelated to the use of the software 
> with the SL grid(s).



The preamble specifically states that the policy only applies to viewers 
meant to be used by SL. In essence, LL reserves the right to deny access 
to viewers that don meet their requirements.


MY concern is about prototyping viewers. I can certainly add a thing to 
timestamp a version string during login, but with smalltalk, I'm 
constantly tweaking the code *while* I'm connected to SL. Does this mean 
I have to log out every time I modify something in my squeak client just 
so I can change the version string?

Even if I don't change the SL viewer code, but only something else in 
the Squeak image, its still part of the same application due to how 
Smalltalk works. So any time I'm connected to SL using smalltalk, and I 
play with the workspace to test a new one-liner, I'm effectively 
changing the viewer code, and must log out and back in with a new 
version string...

Only partly joking here. Taking this policy to its extreme may sound 
silly, but people are correct: its poorly worded.





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] Third party viewer policy

[Lawson English]

Latif Khalifa wrote:
> It also means that now I need to hire a lawyer in order to continue to
> make and distribute my text viewer (Radegast), with special features
> aimed at people with disabilities. The terms mandate that I need to
> have an official privacy policy published, and I also need to to show
> SL ToS to users (and I have no idea where would I get it, and how to
> tell if it's updated). "Shared experience" clause doesn't even deserve
> spending time on it.
>   


If a media plugin provides collaboration between participating viewers 
and doesn't update the sim, or only updates the sim with a view-only 
version of what people are working on, does this violate the "shared 
experience" clause?

What about musicians sharing sound data between themselves via client 
plugins and doing mixing before uploading the sound to the sim?

And what about the VWRAP proposal to let clients establish connections 
for external services via capabilities? Such a capability could easily 
violate the new policy. Lots of vague stuff in this policy.


L.




> On Tue, Feb 23, 2010 at 9: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
>
>   

___
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

[Lawson English]

Marine Kelley wrote:
> You gotta be kiddin me !! I call that a stab in the back. You guys 
> disgust me.  
>
>1. Your Third-Party Viewer name must not be confusingly similar to
>   or use any part of a Linden Lab trademark, including “Second,”
>   “Life,” “SL,” or “Linden.” For example:
>  1. You must not have a Third-Party Viewer name that is
> “ Life” where “” is a term or series of terms
>

I wonder if 二回♀will violate this


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] Third party viewer policy

[Lawson English]

Ryan McDougall wrote:
> On Tue, Feb 23, 2010 at 10:31 PM, Soft Linden  wrote:
>   
>> If you see any wording that's ambiguous about that, let us know.
>> 
>
> Section 3.b.iii says that Third-party viewers must comply with the GPL 
> license.
>
> What if the view is not licensed under the GPL at all -- say Apache 2.0?
>
> Cheers,
>   

For a real life use case, the realxtend developers are currently 
debating whether or not it is worth their while to continue to add more 
support to SL rather than just go with OpenSim-only.

If LL's aim was to squelch all third party work on SL-compatible 
viewers, they've done admirably.

If not, they've just shot themselves in the foot with a blended metal 
bullet:

http://www.metacafe.com/watch/180211/blended_metal_vs_ham/


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] DRM vs TOS Was: Third party viewer policy

[Lawson English]

Dzonatas Sol wrote:
> Lawson English wrote:
>   
>> For a real life use case, the realxtend developers are currently 
>> debating whether or not it is worth their while to continue to add more 
>> support to SL rather than just go with OpenSim-only.
>>
>>   
>> 
>
>
> If any viewer is under GPL terms, rather it is derived or not, it 
> probably won't comply with the TOS if the TOS mandates DRM.
>
> Software that runs on hardware that enforces DRM is not different than 
> software that connects to a service that enforces DRM.
>
> Obviously, basic login credentials aren't being seen as DRM, yet MAC 
> address, channels, and other means to enforce control of the client 
> software, especially through TOS policy, is DRM.
>
> All those discussion's we've had on this list about "signed-off" scripts 
> and programs, even encrypted, have had their rug pulled. Even 
> Microsoft's one-click programs are affected.
>
> I wouldn't say LL backpedaled on the GPL, yet I will say the DRM 
> movement is highly questionable. I can understand why realxtend would 
> want to not continue support for SL with such cloud of questions. This 
> would have been prevented if...  you know, there is a big elephant in 
> the room.
>
>   

the Naali viewer is from-scratch under a freebsd license. No GPL code at 
all.


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] Third party viewer policy

[Lawson English]

Carlo Wood wrote:
> On Tue, Feb 23, 2010 at 12:45:01PM -0800, Brent Tubbs wrote:
>   
>> For a while I've been batting around the idea of creating an SVN-bot to 
>> enable
>> much-improved version control for inworld scripts; a must-have when you're
>> developing as part of a team.  The same-creator policy on content export 
>> would
>> seem to prohibit that though.
>>
>> I realize that you probably don't want to have different rules for each
>> different content type, but the one-size-fits-all rule in the current policy
>> doesn't fit scripts well at all.
>> 
>
> I didn't even READ the TVP all that well, I'm just going to
> stubbornly use my own common sense. If anything that is not
> common sense is going to be enforced then by all means I don't
> want to be part of SL anymore.
>
> In this case the common sense says: If something is full perm,
> you may export it. Second Inventory does this, and I doubt
> that is suddenly made illegal.
>
>   
Actually that is NOT common sense. When the author of some intellectual 
bit of property agrees to distribution, its generally for existing 
channels of distribution only. The SL TOS only applies to intellectual 
property distributed by Linden Lab in the manner that the content 
creator agreed to. Someone ELSE coming along and saying "oh, full perms 
means I own the IP rights to this and can take it anywhere I please and 
do anything I want in any way I want without consideration for the 
original creator" goes against even the CC license, and the LL full 
perms isn't the CC license or any kind of abbreviation of it.




> Scripts that a team work on are definitely full-perm (from the
> point of view of SL permissions), so you can export it all
> you like.
>
>   
Who says? If they don't say so, then legally, full perms stuff is only 
full perms for SL use. If the content creator(s) give you permission to 
move stuff around, that's different, but YOU don't have the right to 
assume such things without explicit permission concerning this specific 
point. Your right to "own" stuff only exists within the SL framework. 
Outside the framework, the IP rights of the content creator 
automatically revert to them.

Or such is how I have had it explained quite a few times over the years.


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

[opensource-dev] realxtend retreating from SL support... ?

[Lawson English]

realxtend list: http://groups.google.com/group/realxtend

[ thread:  Naali will never run on Second Life?


How can you guys claim to be working on interop with IETF when suddenly 
no independent implementation of the viewer works with the SL protocols 
and your new viewer policy is scaring everyone away from working on 
interop? So much for "2 independent implementations": word is that even 
the libomv text viewers aren't working any more.




Lawson (sheesh)
___
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

[Lawson English]

Dzonatas Sol wrote:
> Given this setup. It would look like this:
>
> [ viewer <-> opensim ] <-> [ opensim <-> viewer ]
>
> That's peer to peer.
>   

Another variation of peer to peer is:

[ viewer ] <=> server <=> [ viewer ]
...\.../
\./
.<===>


The viewers talk to each other or to a remote server separately from the sim 
server and share content via that channel instead/as well. "Content" could be 
prims, physics, etc.


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] "Second-Party" viewer policy (was: Third party viewer policy)

[Lawson English]

David Simmons wrote:
> The common sense rules apply. If you are not connecting to the LL
> grid, Linden Lab can't make any policy regarding what you do. They
> don't need a policy saying that they can't make a policy telling you
> what to do on another grid.
> They are just trying to put into policy what LL has expressed in one
> way or other over the years. Remember policy are not written for those
> that are honest, but for those that are dishonest and having a way to
> enforce it. For example; in my workplace we have an 1/2 hour lunch. I
> have yet to see a supervisor watch the clock on anyone, but if someone
> decides to take off for 2 hours and call it lunch, they will be in
> trouble.
>
>
>   
You have nice supervisors who don't hold a grudge against anyone, or 
whose superiors don't hold a grudge against anyone.

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

[opensource-dev] [Fwd: [realXtend] Presentation of naali viewer and realXtend to AW Groupies...]

[Lawson English]

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
--- Begin Message ---

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

--- End Message ---
___
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

[Lawson English]

We DO use Second Life chat, afterall...


Argent Stonecutter wrote:
> If you don't mind days round trip for each line of chat.
>
> On 2010-02-28, at 14:05, Dzonatas Sol wrote:
>
>   
>> This is perfect then...
>>
>> 
[...]
___
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] BSD viewer talk from realXtend. Tuesday, 8:30 AM SLT

[Lawson English]

Tuesday's AW groupies meeting will be held an hour early at 8:30 AM PST at
http://maps.secondlife.com/secondlife/ThorneBridgeTown/156/130/22

We will be hearing from members of the realxtend team about their naali 
viewer project and other realxtend stuff. Realxtend is an organization  
creating a SL-compatible virtual world sim software based on OpenSim. 
Naali is a from-scratch viewer that is being developed independently of 
Linden Lab.


http://www.realxtend.org/http://opensimulator.org/wiki/RealXtend

some background and current dev focus:

http://wiki.realxtend.org/index.php/Platform_Extensibility_Working_Group

IM Saijanai Kuhn in-world for a Groupies invite if the SLURL doesn't work.


Cya there.


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] BSD viewer talk from realXtend. Tuesday, 8:30 AM SLT

[Lawson English]

Lawson English wrote:
> Tuesday's AW groupies meeting will be held an hour early at 8:30 AM PST at
> http://maps.secondlife.com/secondlife/ThorneBridgeTown/156/130/22
>
>   

Chatlog from meeting:  
https://wiki.secondlife.com/wiki/AW_Groupies/Chat_Logs/AWGroupies-2010-03-02


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

[Lawson English]

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

Re: [opensource-dev] Eclipse Guru's

[Lawson English]

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 
>  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 and plugins.


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

Re: [opensource-dev] Client Plugin System Design

[Lawson English]

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

[opensource-dev] SnowGlobe/viewer 2 streaming media issue with new prim textures

[Lawson English]

https://jira.secondlife.com/browse/SNOW-566

This is a reference to: https://jira.secondlife.com/browse/VWR-17151


There are 14 votes for VWR-17151 in pJIRA, but I can't find a 
reference/link to it in any SnowGlobe jira and the issue shows up in my 
hand-built SnowGlobe 2 viewer, AND to some extent, in the viewer plugin 
test app bundled with SG2.


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] Fwd: Request for comments about llSetAgentEnvironment / SVC-5520

[Lawson English]

Soft Linden wrote:
> On Sun, Mar 14, 2010 at 1:32 PM, Ryan McDougall  wrote:
>   
>> I'm not interested in how to humbly coax LL's
>> good will on bended knee
>> 
>
> And that's not what has been asked of you. The rest of your post hangs
> on that mischaracterization.
>
> When you're on the realxtend list, you're civil and encourage
> participation. I assume that's because you know that's what's involved
> in making a project work. I'm asking for a similar baseline here if
> you want to remain involved.
>   

Maybe you guys should take this to Groupies? We tend to thrive on cat 
fights...

;-)

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] oh give me a break

[Lawson English]

Tori C. wrote:
> On Sun, Mar 14, 2010 at 3:09 PM, Kent Quirk (Q Linden)  
> wrote:
>
>   
>> We actually believed we were doing something the community would really 
>> appreciate -- getting the source out there the same day as beta. And yet 
>> somehow that became something bad. People keep repeating that "it's closed 
>> source".
>> 
>
> There is some appreciation out here! Some of us are happily running
> 2.0 on PPC Macs and that wouldn't have been possible without the
> sources. Kind of funny, but end user hostility pretty quickly put the
> damper on any enthusiasm we had for sharing that porting work, and
> performance tweaks wanted by the platform's shortcomings, outside a
> small group of friends.
> ___
>   

Torri, have you let the Macintosh User's Group know you have done this? 
Quite a few PPC users are kinda down about the whole issue right now.


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] oh give me a break

[Lawson English]

Lance Corrimal wrote:
> Am 14.03.2010 20:37, schrieb Soft Linden:
>   
>> On Sun, Mar 14, 2010 at 12:23 PM, Lance Corrimal
>>  wrote:
>>   
>> 
>>> Am 14.03.2010 18:56, schrieb New Hax:
>>> 
>>>   
 Lindens should be staying with their promises
   
 
>>> related question, where's the svn repo to check out the server code?
>>> 
>>>   
>> How is that in any way related?
>>
>> We're closer on some of the tech, but don't yet operate with a
>> business model where giving away the hosting business would make
>> sense. Nobody promised otherwise.
>>   
>> 
> I might be totally wrong but I remember phil saying that the server code
> would be open sourced as well, back when snowglobe started...
>
>   

That was the intent, but I think things got away from them. By all 
accounts, the server code is even more scary thant he viewer code was 
when first released and with OpenSim and a C++ implementation on its 
way, releasing the SL code makes no real sense for LL, IMHO.


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] oh give me a break

[Lawson English]

New Hax wrote:
> then what are you doing on an opensource list if you want your content
> wrapped in DRM.
>
> sl will die if its not open. and you can't compare rl doors to the
> internet. if you dont lock your rl door I can come in and take
> something of yours that isnt replaceable.
>
> but on the internet as a content maker you can make INFINITE products
> so you arent losing anything if i copy it and make no money off of it.
>
>   

So lets open up all scripting sources too. I mean no need for content 
protection there, either, right?


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] oh give me a break

[Lawson English]

New Hax wrote:
> No im not kidding, whats going to stop people from taking your
> scripts, when you can hop from one grid to another? Interoperability?
> The sim owner can take your scripts.  For now scripts are protected
> because Linden Labs owns the code.
>   

THere are plenty of ways in which scripts could be protected for 
interop. If a compnay has sufficiently storng trust agreements with LL, 
LL might be willing to share the source, for exxample. Another proposal 
(by Zero linden) is that attached scripts might by run on their own 
server, separate from teh host sim's. There are ways of encrypting 
content that make it difficult (though not impossible) to steal stuff of 
any kind. Google references to the E language and virtual world assets 
for more info.


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] oh give me a break

[Lawson English]

Vex Streeter wrote:
> Soft Linden wrote:
>   
>> Any additional ideas on squashing fraud are always appreciated, via
>> mail to secur...@lindenlab.com. Please don't hold those discussions on
>> this list.
>>   
>> 
> Understood - I know there is considerable effort in this area.  Mainly I 
> wanted to opine that such limits are much more effective than DRM at 
> discouraging profit-motive copyright infringement.
>
>
>   

Well, "DRM" the SL permissions system ain't but it IS a "digital rights 
management system" in the broader sense that it is meant to enable at 
least legal protections against IP theft...

...and, the one court case I'm aware of almost established that it is 
sufficient for taking legal action. At least the judge didn't toss the 
case out of court at first glance.

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] oh give me a break

[Lawson English]

Tigro Spottystripes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> People can still simply sell the L$ for a fraction of the market price
> directly to other people, without ever going thru an exchange service,
> that's how i would do it if i wanted to cash out illegal money. Trying
> to limit usage of exchange services only works for the dumber outlaws.
>   


Except ALL L$ transactions are monitored. Give someone $L 1,000,000 in 
one chunk or in one million chunks, and it will still trigger alarms.


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] oh give me a break

[Lawson English]

Tigro Spottystripes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Are the people selling illegal copies making that much money that fast?
>
>
>
>   
I was thinking more in terms of drug laundering and the like, not 
revenue from selling stolen prims. Jumped off-topic a tad, sorry.


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] Meadhbh Hamrick is no longer at Linden Research

[Lawson English]

Hey Meadhbh, I was sad to hear that news. You'll still be lurking in 
Groupies once in a while, I hope.

Lawson (Saijanai)

Meadhbh Hamrick wrote:
> Hey Everybody,
>
> As many of you know, over the past year I've been working for Linden
> Research on virtual worlds interoperability. Specifically, I've been
> working with the IETF to establish working groups to develop open
> virtual world interoperability. I've also been writing internet drafts
> and supporting third party developers who are implementing the VWRAP
> specifications.
>
> But recently, I left the lab. The decision was amicable and mutual. It
> does not mean the lab has abandoned it's work on interoperability;
> only that it will be done by a different team. I am continuing to
> participate in the Virtual World Region Agent Protocol working group
> at the IETF and will likely author or contribute to further internet
> drafts.
>
> I'm happy to talk to anyone regarding generic virtual world
> architecture issues, but clearly specific questions regarding second
> life and linden's future plans for VWRAP should be directed to the
> lab.
>
> -Sincerely
> -Meadhbh Hamrick (formerly Infinity Linden)
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * ohmead...@gmail.com
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>
>   

___
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] Virtual Worlds workshop topics include interop and realxtend

[Lawson English]

quick reminder 6am for the start of Tuesday's session on Virtual Worlds 
Workshop. Topics will include realXtend. Presenters will include Python 
Morales from realXtend and Zha Ewry from IBM
 http://slurl.com/secondlife/IBM%20Business%20Center2/65/1/27
http://vw.ddns.uark.edu/X10/X10--Schedule.html

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] new TOS - TPV "legally" binding. :/

[Lawson English]

Lance Corrimal wrote:
> just had a little popup shoving the new TOS under my nose, and behold, 
> with accepting the TOS you also accept the TPV.
> ___
>   
I wonder if that's even legal...


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] new TOS - TPV "legally" binding. :/

[Lawson English]

Gareth Nelson wrote:
> You're always welcome to not accept the TOS and thus lose all
> your inworld assets
>
> On Wed, Mar 31, 2010 at 4:58 PM, Lawson English  wrote:
>   
>> Lance Corrimal wrote:
>> 
>>> just had a little popup shoving the new TOS under my nose, and behold,
>>> with accepting the TOS you also accept the TPV.
>>> ___
>>>
>>>   
>> I wonder if that's even legal...
>>
>>
>> 
Well, my point is that a click-through agreement with side-effects that 
no-one understands doesn't sound like a particularly binding agreement 
or even an agreement at all.

I mean, LL could put in: "when you agree to this you are agreeing to the 
provision that your First Born will be sacrificed to FSM at our 
convenience," if they wanted to, or any other reference to any other 
future situation that has no relevance to the main intent of the EULA...


This doesn't sound sufficiently focused to stand up in a court of law.


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] [vwrap] "What's *not* in VWRAP" - presentation in SL April 20 @ 9:30am Pacific

[Lawson English]

 From VWRAP list:

David W Levine wrote:
>
> http://maps.secondlife.com/secondlife/ThorneBridgeTown/162/134/22
>
> That's the ThorneBridgeTown  IBM Research sim, if you want a teleport 
> offer, tap Zha Ewry in world sometime around or after  9:20 PDT
>
>
>
> From: Joshua Bell 
> To:   vw...@ietf.org
> Date: 04/19/2010 06:14 PM
> Subject:  [vwrap] "What's *not* in VWRAP" - presentation in SL April 
> 20 @9:30am Pacific
> Sent by:  vwrap-boun...@ietf.org
>
>
> 
>
>
>
> Unless there's been a last minute schedule switcheroo I'm unaware of,
> I'll be presenting "What's *not* in VWRAP - a dissection of the Linden
> Lab Legacy Protocol" to the AWGroupies in Second Life on Tuesday,
> April 20th (thats tomorrow!) at 9:30am Pacific.
>
> I'm actually unsure of where the session will be held in-world. Can a
> regular please reply with a SLURL?
>
> This was material I'd intended to present at IETF77 in Anaheim but
> great content from other presenters took priority. The slides are
> linked from https://datatracker.ietf.org/meeting/77/materials.html but
> stick to the source at
> https://docs.google.com/present/edit?id=0AfAytYlNCPECZGZ2M24yMl8yN2N0OGJueGNy&hl=en
>  
> 
> (I'm not planning on any last minute edits, though!)
>
> For those who look through the slides but may miss the context of the
> presentation:
>
> * The talk tries to give listeners a framework to answer the oft-asked
> question "When will XYZ be standardized in VWRAP?"
> * The talk is intended to be provocative; the slides make some bold
> claims I'm expecting the audience to take issue with!
> * There is no call for consensus on topics; contrariwise, there are
> calls for opening up discussions
> * It is not presented with any sort of implied authority, either as
> co-chair to the WG or as an employee of Linden Lab. The working group
> is highly encouraged to disagree with any of my reasoning or
> conclusions!
>
> The in-world presentation will not be under the auspices of the IETF
> (i.e. "Note Well" does not apply); any extensive discussion will be
> directed to this list, though.
> ___
> vwrap mailing list
> vw...@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
>
> 
>
> ___
> vwrap mailing list
> vw...@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>   

___
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] kindof OT but .. Teens on the Main grid (linden response only please)

[Lawson English]

FoxSan Yosuké wrote:
> Holy crap, thats a professional answer O.o
>
> 2010/4/26 Kelly Linden mailto:ke...@lindenlab.com>>
>
> The linden response is nothing that others couldn't tell you:
> * This is not the list for it.
> * 
> http://wiki.secondlife.com/wiki/Linden_Lab_Official:How_to_report_an_underage_Resident_in_Second_Life
>
"If you're between the ages of 13-17 and somehow ended up on adult 
Second Life, please contact Support and let us know that you'd like to 
be moved to the correct grid. If you think it would be funny, you can 
also file an Abuse Report against yourself, with your name and age. Your 
honesty is appreciated, and we hope you'll make lots of new friends 
while having fun in Teen Second Life!"


I like that last part--wonder if anyone ever does that...


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] kindof OT but .. Teens on the Main grid (linden response only please)

[Lawson English]

Tigro Spottystripes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hm, well, if they are gonna be nice like that, then go ahead, get the
> teen to self-AR themself. :)
>   

Could bring back The Cornfield and only make it available for teens that 
self-AR.


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] Plugins/Modular architecture

[Lawson English]

  On 9/2/10 8:13 AM, Talia Tokugawa wrote:
> [...]
> I know this has been suggested before as friends have suggested it. 
> Why not make the viewer more Modular? Introduce a plugin architecture. 
> Allow any user to "build" their own client that fits their needs and 
> requirements.
>

Its a HUGE undertaking to do that. LL wasn't willing to tackle the issue 
directly years ago and they probably don't have the resources to do it 
now. It would have to be a community-lead effort and I'm not sure that 
developers are willing to invest the time to refactor the viewer at that 
level unless LL will be willing to seriously consider using the 
resulting re-architectured viewer.


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