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

[Dzonatas Sol]

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

[Dzonatas Sol]

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

[Dzonatas Sol]

Morgaine wrote:
> Dzon:  Nice parable. :-)

Thank you. Unfortunately, some still challenge it as if they know the 
only answer, yet they should read up on Proton Exchange Membranes, 
especially Zero-Emission, for proof.

For a business to use patented method in their employment process was 
quite remarkable.Sometimes people get jurassically blindsided by... scale.


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

I would go with three. Call the third one: "*Transient Scripts & 
**Transient **Array*s", or something similar with the word "transient" 
being significant.More successful designs have included this third area.

Basically, in the transient area, you wouldn't want the responsibility 
of the existence any particular script to fall upon the corporal 
location of such script, not that the corporal is entirely excluded from 
being responsible.There is a balance that is needed, and it is best to 
keep the nature of the balance away from the two other areas you described.

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

Good. I would think extensions might confuse what direction they extend 
from, however. If we are to maintain balance, and responsibility, then 
we need to know that direction. The scripts on the client side may have 
nothing to do with the client viewer. These same scripts may also seem 
like a server. Easiest to consider these as "processes," yet that has 
been confused by the organically evolved chipsets and thread technology. 
What the "world" only needs to know from the "world" viewpoint are the 
transfer devices, or membranes. Then we have scripts that can and cannot 
be exchanged through the membrane. Those that can't get through the 
membrane, we call "brains" on one scale and "protons" on another scale. 
That'll work for now.


>
> * *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.
That is what the transient area handles.

The only way really possible for completely untrusted scripts and arrays 
to compute on the client side as "world extensions" would be to make a 
complete copy of the original on the other-side of the membrane. That 
isn't always true, yet on the scale of "brains" it's a good idea of 
where to start, not where they would have lost control so easily.

20 years of "fighting" about all this has really set us back.Would have 
been easier if "trust" was actually accepted rather than some paper 
masquerade.


___
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

[Dzonatas Sol]

Marine Kelley wrote:
> Exactly my thinking too, the problem us not clear whether the players  
> are cooperative or in competition. It totally changes the result.
>
> But I guess that the real goal of this challenge is to call you  
> "stupid" and to gauge your reaction. If you yell or punch the  
> recruiter, you're dismissed. If you say "my bad, you're right", you're  
> dismissed. But if you argue and explain your theory clearly, calmly  
> and with the objective of solving the problem instead of just  
> defending yourself, you prove that you're someone who can integrate a  
> team that works on a system that is both technical and social.
>
>
>
>   

Hmm. Let's think about this for a few...

The players are imperfect...

One is the recruiter that knows nothing about the recruitee...

The recruiter calls the recruitee "stupid"

In the reality of the recruitee, kids are missing (as in stolen), 
undergoing unknown symptoms of major depression, blisters on feet from 
working more than 40 hours a week, on up to 80 hours a week to keep 
family together for more than a year, pressured to work more due to 
legal problems, almost on the street due to leftover money not meeting 
needs, etc etc (this is not made up)

If the recruitor has no knowledge of this, which they shouldn't because 
of employment laws, then to call the recruitee "stupid" and for the 
recruitee to act any bit calm would be a major ability to stay calm 
under such hardship... even if the recruitee just simply said "my bad, 
your right" just to pass up an unfair question and explain anything now 
going on in the mind of the recruitee.

Major Depression Disorder is a disability that would be exploited by 
such question, and this recruitee would never get hired due to this 
disability, which is against law to not hire someone because of a 
disability.

The reruitee states the obvious and the recruiter takes it as a legal 
threat, which questions the ability of how this ever will work as a team 
on a system that is both technical and social... where both win.

Long story short... but one is still losing, so when does the "fighting" 
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

[opensource-dev] DRM vs TOS Was: Third party viewer policy

[Dzonatas Sol]

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

[Dzonatas Sol]

Lawson English wrote:
> 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
>
>


I can hit that Infinite Button of 'what see what this does' too??? They 
make great bitch points.
___
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

[Dzonatas Sol]

Jason Giglio wrote:
>> Legal is aware that there has been confusion on this. There will be an
>> update soon, which makes the terms more clear.
>> 
>
> Is it an actual update to the policy document?
>
> Not a mere FAQ that says "Oh we didn't really mean what the policy says
> in plain English"?
>   

Don't you love how layers say "oh but we mean these terms only in this 
sense" but in court they say "to the fullest extent of the law."

Earth World Version 2012...

Day awaits for court where we measure patents and who really means what. 
I, and others, don't need lawyers to say "oh but we mean this..."

This isn't a threat, it's just stupid common sense.
___
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

[Dzonatas Sol]

Given this setup. It would look like this:

[ viewer <-> opensim ] <-> [ opensim <-> viewer ]

That's peer to peer.

Let's say somebody wants to setup a 3D website inside one. They don't 
want to go through ICANN because it's "virtual" just like "virtual 
linden" currency.

They want "http://media.on.a.prim.region.open.sim"; as their website.

They point and click, create object, select media prefs, enter website 
address, they get the TLD automatically, no hassle to reg with ICANN for 
every prim they create. And, no need to have a static server, any other 
simulator may connect to their simulator and find their website.  That 
way someone may "buy" their prim, take it to another world, and use it 
there, and the website still works and knows how to resolve addresses.


Dahlia Trimble wrote:
> I have been experimenting with combining and/or offloading physics 
> simulations on physics capable clients (not LL based) with OpenSim, 
> but nothing has been released as open source as of yet. It's not clear 
> to me how a new TLD would affect this though, or why it might be 
> required.
>
> -Dahlia
> (Core)
>
> On Thu, Feb 25, 2010 at 11:05 AM, Dzonatas Sol  <mailto:dzona...@gmail.com>> wrote:
>
> I thought this was quite of interest for viewer developers that
> might ever be interested to attach a simulator to their viewer in
> order to dispel latency.
>
> --- snip ---
>
> If one opensim box connects to another opensim box, that is,
> technically, peer to peer.
>
> So, are you saying an opensim box cannot run a client at the same
> time?
>
> >Melanie wrote:
> >Hi,
>
> >peer to peer simulation is not practical for many different reasons.
> >Latency being the chief one.
> >
> >OpenSim is not going to be a peer to peer system, therefore your
> >suggestion is off topic. Opensim doesn't need another TLD, and it is
> >not what you are envisioning. OpenSim firmly embraces the concept of
> >SERVER SIDE simulation, therefore every sim will always have a
> >central server.
> >
> >I believe this has gone as far as it will go and if there is any
> >more name calling, well, we'll just have to moderate some people,
> >won't we?
> >
> >Melanie
> >(Core)
>
> If one opensim box connects to another opensim box, that is,
> technically, peer to peer.
>
> So, are you saying an opensim box cannot run a client at the same
> time?
>
> Melanie wrote:
>
> Hi,
>
> peer to peer simulation is not practical for many different
> reasons.
> Latency being the chief one.
>
> OpenSim is not going to be a peer to peer system, therefore your
> suggestion is off topic. Opensim doesn't need another TLD, and
> it is
> not what you are envisioning. OpenSim firmly embraces the
> concept of
> SERVER SIDE simulation, therefore every sim will always have a
> central server.
>
> I believe this has gone as far as it will go and if there is any
> more name calling, well, we'll just have to moderate some people,
> won't we?
>
> Melanie
> (Core)
>
>
> �
>
>
>
>
> ___
> 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] TPV & opensim

[Dzonatas Sol]

I thought this was quite of interest for viewer developers that might 
ever be interested to attach a simulator to their viewer in order to 
dispel latency.


--- snip ---

If one opensim box connects to another opensim box, that is, 
technically, peer to peer.


So, are you saying an opensim box cannot run a client at the same time?

>Melanie wrote:
>Hi,

>peer to peer simulation is not practical for many different reasons.
>Latency being the chief one.
>
>OpenSim is not going to be a peer to peer system, therefore your
>suggestion is off topic. Opensim doesn't need another TLD, and it is
>not what you are envisioning. OpenSim firmly embraces the concept of
>SERVER SIDE simulation, therefore every sim will always have a
>central server.
>
>I believe this has gone as far as it will go and if there is any
>more name calling, well, we'll just have to moderate some people,
>won't we?
>
>Melanie
>(Core)
--- Begin Message ---
If one opensim box connects to another opensim box, that is, 
technically, peer to peer.


So, are you saying an opensim box cannot run a client at the same time?

Melanie wrote:

Hi,

peer to peer simulation is not practical for many different reasons.
Latency being the chief one.

OpenSim is not going to be a peer to peer system, therefore your
suggestion is off topic. Opensim doesn't need another TLD, and it is
not what you are envisioning. OpenSim firmly embraces the concept of
SERVER SIDE simulation, therefore every sim will always have a
central server.

I believe this has gone as far as it will go and if there is any
more name calling, well, we'll just have to moderate some people,
won't we?

Melanie
(Core)


  



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

[Dzonatas Sol]

If there is no need for a grid server, then there would be no need for a 
TOS that would try to control a TPV.

I see the issue of opensim that wants to say "can only connect client to 
a grid server as supported by opensim" no different than Linden Lab's 
new TOS in attempts to control TPVs.

If we modify LL's official viewer and add client-side simulation to help 
dispel latency, with physics prediction, then their TOS says "no," you 
have to register your special viewer to connect.

Melanie stated that opensim is grid server only (like a TOS), which in 
essence, is logical equivalent to say, "you can't modify opensim in 
order to add a viewer and connect to our grid server"

One obvious question is: who's grid server?

With physics prediction being equal peer to peer, why would there ever 
need to be a grid server, or a TOS?

 >>> You're confusing the architecture of the software with what people 
want to do with it.

So, are they saying they don't want physics prediction?

Robert A. Knop Jr. wrote:
> On Thu, Feb 25, 2010 at 10:34:08AM -0800, Dzonatas Sol wrote:
>   
>> If everything is peer-2-peer where each client runs it's own simulator, 
>> there would be no need for a grid server. It's foolish and stupid to 
>> consider people would only want to connect to a grid server. That's 
>> certainly not how reality works, so it would be stupid to expect that 
>> when simulated.
>> 
>
> ...and, in OpenSim right now, there's no need for a "grid server".  You
> run a standalone region, and you've got your region without having some
> grid server.
>
> But it's not purely peer-to-peer, because the viewer software and the
> server software are two different pieces of software.
>
> It's just like how I can run Apache (web server) on my desktop, and use
> Firefox (web client) on my desktop to look at HTML documents served by
> Apache on my desktop.  It's all on my machine, and I don't have to rely
> on any web hosting provider or any such to complete the transaction.
> But it's not p2p in the sense that it's still a client-server
> architecture.
>
> You're confusing the architecture of the software with what people want
> to do with it.  Things don't have to have a peer-to-peer architecture
> for everybody to be able to roll their own.  There are advantages and
> disadvantages to different architectures for different problems.  But
> the fact is that OpenSim is a client/server architecture, and that's how
> it is.
>
>
>   
> 
>
> ___
> Opensim-dev mailing list
> opensim-...@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>   

___
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

[Dzonatas Sol]

I had this question but didn't see a response to it at all: "So, are 
they saying they don't want physics prediction? "

To me, a direct protocol, with a TLD, like "opens.im" , would help 
enable physics prediction where two or more simulator share the same 
dataset for a single region. There are exponential reasons why, so I 
only have avoided to describe all potential possibilities.

The issue of latency seems like a major concern for ALL users, not just 
those who invest in a grid server.

As I started this conversion, I brought up the UUCP domain, as it 
traditionally shows the foundation of p2p networks and how to share 
datasets with simple copy programs. Look at all the traffic on USENET 
that was still delivered to all nodes even on what we would consider now 
the slowest of computers and data connections. People used a similar 
VIEWER<->UUCP<->UUCP<->VIEWER to read news and distribute all the datasets.

It worked. It is still free and open.

All what we really want to do is add a 3D renderer and physics 
simulator. Everything else is already open source, patented, RFC'd, and etc.

Also, since "prims" are in-world, we also just want to add an "in-world 
DNS" that is not controlled by a "out-of-world IANA" -- I don't think 
this was acknowledged. Some can simply think of an LSL script in-world 
that acted as the DNS program, if that helps clarify.

Robert A. Knop Jr. wrote:
> On Thu, Feb 25, 2010 at 12:40:27PM -0800, Dzonatas Sol wrote:
>   
>> If there is no need for a grid server, then there would be no need
>> for a TOS that would try to control a TPV.
>> 
>
> ...and OpenSim has no such TOS.
>
>   
>> If we modify LL's official viewer and add client-side simulation to
>> help dispel latency, with physics prediction, then their TOS says
>> "no," you have to register your special viewer to connect.
>> 
>
> ...to *Second Life*.  Not to connect in general.
>
> You're confusing Second Life, which is a single proprietary service run
> by a single company, with OpenSim, which is a software platform that can
> be deployed by anybody.
>
>   
>> Melanie stated that opensim is grid server only (like a TOS), which
>> in essence, is logical equivalent to say, "you can't modify opensim
>> in order to add a viewer and connect to our grid server"
>> 
>
> Wrong.
>
>   

___
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

[Dzonatas Sol]

Lawson English wrote:
> 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 ]
> ...\.../
> \./
> .<===>
>
>
>   


In X11 terms, it would be

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



Hmm, it is the server that renders the world, so the "client" is in () 
parens here:

[ viewer <-> ( opensim ] <-> [ opensim ) <-> 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

Re: [opensource-dev] FAQ posted for Third Party Viewer Policy

[Dzonatas Sol]

Soft Linden wrote:
 >> 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.

*looks like a rabbit that hops around with a timeclock on paw*


"One Sim Per Avatar"

Of course, these can work perfectly while Linden Lab's distributes their 
simulator software as closed sourced, as a module, to open source.

I can only suggest to lean towards GPLv3 for the final movement on such 
connection.

Then it certainly won't look like control for control purposes.

However, *winks* at rabbit(s)
___
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

[Dzonatas Sol]

This is perfect then...

If you are scheduled to meet in a sim later in the week, then why worry 
if all the static objects take a day to download from that sim through 
archaic usenet means. You would already have all the object information 
needed for physics and to render in a local storage.

By the time everybody meets, there would be no lag to suddenly download 
all objects from a single host.

Times that by 10,000 people... just for scalability concerns.

Argent Stonecutter wrote:
> On 2010-02-25, at 15:12, Dzonatas Sol wrote:
>> [Usenet] worked. It is still free and open.
>
> It used to be. It's getting harder and harder to get feeds these days. 
> Everyone just reads through Google Groups rather than trying to find 
> someone with a feed. SL and OpenSim started with the equivalent of 
> "Google Groups" already live.
>
> It wasn't even vaguely real-time. It was *OK* that the 
> stanford-munnari link was a daily airmailed magtape, nobody cared if 
> their newsfeed was a day behind.
>
>

___
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

[Dzonatas Sol]

Being able to distribute physic data about objects in a passive manner 
has nothing to do with being able to network chat itself in a 
non-passive manner.

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...
>>
>> If you are scheduled to meet in a sim later in the week, then why  
>> worry if all the static objects take a day to download from that sim  
>> through archaic usenet means. You would already have all the object  
>> information needed for physics and to render in a local storage.
>>
>> By the time everybody meets, there would be no lag to suddenly  
>> download all objects from a single host.
>>
>> Times that by 10,000 people... just for scalability concerns.
>>
>> Argent Stonecutter wrote:
>> 
>>> On 2010-02-25, at 15:12, Dzonatas Sol wrote:
>>>   
>>>> [Usenet] worked. It is still free and open.
>>>> 
>>> It used to be. It's getting harder and harder to get feeds these  
>>> days. Everyone just reads through Google Groups rather than trying  
>>> to find someone with a feed. SL and OpenSim started with the  
>>> equivalent of "Google Groups" already live.
>>>
>>> It wasn't even vaguely real-time. It was *OK* that the stanford- 
>>> munnari link was a daily airmailed magtape, nobody cared if their  
>>> newsfeed was a day behind.
>>>
>>>
>>>   
>
> "Welcome back, Anonymous, we're glad to see you again!"
>
>
> ___
> 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

[Dzonatas Sol]

Argent Stonecutter wrote:
> On 2010-03-01, at 20:38, Dzonatas Sol wrote:
>> Being able to distribute physic data about objects in a passive 
>> manner has nothing to do with being able to network chat itself in a 
>> non-passive manner.
>
> Oh, OK, so you're just talking about it taking days to rez a prim?
>
If someone is scheduled to appear in a sim a week from now, then it 
doesn't matter if it takes 1 to 6 days to download, cache, and rez a 
prim locally on the 7th day of the scheduled meeting.
___
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

[Dzonatas Sol]

Argent Stonecutter wrote:
>
>> If someone is scheduled to appear in a sim a week from now, then it 
>> doesn�t matter if it takes 1 to 6 days to download, cache, and rez a 
>> prim locally on the 7th day of the scheduled meeting.
>
> Given the way SL works, and the way people use it, this is an 
> extremely unlikely scenario:
>
> * You're scheduling a meeting 7 days ahead.
> * There's not going to be any need to rez any prims that aren't 
> already in the sim at any time during the meeting.
> ** Or less than 7 days before the meeting.
> ** Including attachments.


SL4B... SL5B... SL6B...  3 examples, it's already likely

Let's add "burning man" event... so that is how many more sims!

All "static" objects easily list as pre-scheduled distributable physics.

Evolved functionality could include static objects attached to avatars, 
as they reserve space (by sign-up, rsvp, etc.)

Evolved functionality on scripted objects that are not interactive are 
eligible for selection (to pre-schedule distribution).

Passive effects that avatars do not affect are also eligible.

Sounds and animations are also eligible for the pre-scheduled list.

This chapter continues


___
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

[Dzonatas Sol]

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


Evolution of load balancers can handle the bulk of static objects that 
finish in a timely manner. Reservation of virtual land parcels easily 
prioritized by a selection of those that already have a build done. 
Those last on the list or late reservation obviously get a sim 
especially set aside for those build not done in a timely manner. The 
main area obviously contains those that are done in a timely manner.

Promotion to devolve virtual lands and move to other systems without 
negotiation requires diplomacy. It's the investors' matter to undo 
current diplomacy.
___
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

[Dzonatas Sol]

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

The REST based system allows for asynchronous and synchronous flow of 
communication with completely detached paths through any possible 
transport mechanism provided, yet typically HTTP is used.

REST is quite different from the usual SOAP design and implementation 
for messages being passed back and forth. Either way, this is the level 
that plugin or client-side script designer need to think about rather 
than a lower transport protocol.

Be sure to look at the patch here for minimal REST/HTTP server added to 
the viewer:
https://jira.secondlife.com/browse/SNOW-375

That easily allows any plugin or client-side script to connect to the 
viewer like any HTTP based script would do.

Currently, already started to provide resources to work with the 
inventory. My project site: http://jira.dzonux.net:8080/browse/MVC
___
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

[Dzonatas Sol]

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.
>
>
REST doesn't need to be based on sockets. It's just commonly used with 
sockets/HTTP. REST is not the transport layer.

Here is the architecture so it can be better understood: 
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

HTTP could be said to be a specific design category, but not REST.

D-Bus uses XML/socket encapsulation, and is slower (due to conversions). 
You could say D-Bus is a specific design category for 1, also.

Design should also include if the plugin/scripts are in separate 
processes. #3 doesn't allow that easily until made portable. REST/HTTP 
is already portable. D-Bus is somewhat portable, yet harder to interface.

___
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] Client-side scripting REST/HTTP doc sample

[Dzonatas Sol]

Here is a sample of the REST/HTTP doc for SNOW-375.

SNOW-375 adds a HTTP server in the viewer to be easily accessible by any 
process or client-side script in a language agnostic manner.

I posted this here to hopefully encourage forward movement in 
client-side scripting and to avoid the backpedal and reinventions.

Note: This is tried, tested, and works. This is not just "talk" or 
made-up documentation.

+

SNOW-375: REST/HTTP URI patterns and response summary as of March 2010

All names that appears in angle brackets, <>, are variable.

Note full URI paths used, yet these don't include the 
"http://host:port/"; designation.

Example URI: http://localhost:50140/ControlGroup/SavedSettings

All responses are wrapped in LLSD (examples not included in this doc).

Most of these use the GET method, and combined/burst throughput via the 
POST method.


/ControlGroup

Response is a list of control groups.



/ControlGroup/

Response is a list of valid variables in a controlgroup with default 
settings

 is currently either "SavedSettings" or "SavedPerAccountSettings"



/ControlGroup//

Response is a detailed and update of current settings for the specific 
variable identified.

 is currently either "SavedSettings" or "SavedPerAccountSettings"
 is a valid variable name from one of the variable control 
groups.



/Agent/Groups

Response is a list with details of groups joined by the connected agent.



/AvatarTracker/Friends

Response is the UUID list of the agent's friends and basic status of each.



/AvatarTracker/Friend/

Response is a detailed relationship information for a specified friend UUID.



/GestureManager/Items

Response is a list of UUID of active gestures.



/GestureManager/Item/

Response is the details of a MultiGesture structure for the UUID specified.



/Inventory/Item/

Response is the details of an inventory item specified by the UUID.



/Inventory/Root

Response is the UUID of the root inventory folder.



/Inventory/Category/

Response is the UUIDs of the descendant categories and items of the 
specified UUID.



/Asset/Notecard/

Response is the notecard item specified by UUID converted to XML format 
(rather than 'linden notecard format').


/Interface/Connect

POST: Attempt to negotiate a connection to enable the above resources.
* Details of connection steps not included in this doc.


/AvatarTracker/Friend/s
/GestureManager/Item/s
/Inventory/Item/s
/Inventory/Category/s

POST: List of UUIDs for combined query, as above where  is replace 
with just an "s".
Response: List of combined queries as if each item is an individual 
responses to each UUID.


___
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

[Dzonatas Sol]

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.

What some people want is to separate a way to run a sandbox version of 
their LSL code on the client-side, which is a bit different than the big 
picture of client-side scripting in any program language.


Erik Anderson wrote:
> Not to mention that .NET does not have an uncontroversial licensing 
> arrangement, with many lawyers not able to figure out whether or not 
> most linux distributions are in technical violation...
>
> On Wed, Mar 17, 2010 at 9:51 AM, Argent Stonecutter 
> mailto:secret.arg...@gmail.com>> wrote:
>
> > I don't follow you here. What I read in the above was a combination
> > of a well defined client side extension API and a mechanism to load
> > code that can be granted a level of trust based on criteria it needs
> > to do its job. �That might include code signing and metadata about
> > the capabilities the client plugin needs. I don't see any mention of
> > "untrusted binaries" other than the implication that a module that
> > doesn't negotiate additional capabilities gets started in a
> > sandboxed environment with minimal capabilities.
> >
> Any code not explicitly installed by the user is "untrusted".
> Executing untrusted code in a sandbox is an extremely difficult
> operation to perform safely. Doing so in a way that also accepts
> "trusted" code through the same mechanism is something that even
> Microsoft has notoriously failed to successfully pull off... a good
> number of the exploits of the late '90s and early '00s were due to
> failures of this security model.
>
> Doing this securely enough to ship is an extremely difficult
> undertaking, ranking alongside the whole of Second Life in ambition
> and scope, and not doing it securely could destroy Second Life.
>
> I would not use nor recommend using any viewer that implemented 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

___
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

[Dzonatas Sol]

It's still the same concept: to download and install...  they are 
overused buzzwords that make people think there are some elaborate 
separations for the basic ideas on how to migrate processes.

The sandbox model is just another abstraction to unify permissions.

It would be no different to install a linux emulator and use that as the 
sandbox. All sandboxed programs can run directly on the linux emulator.

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

Re: [opensource-dev] Known details of LL 'Firefly' client-side scripting

[Dzonatas Sol]

Somewhere on this list in the past is a discussion about how to sign off 
on scripts and such data for distribution. Those points have already 
been made.

What the sandbox model does is allow people to setup a default 
permission scheme and allow processes to migrate within the sandbox 
without the constant nag "do you want to allow this to run on your 
computer".

Instead, you get something like facebook that says "program XYZ request 
this specific permission, do you allow". If a program doesn't need those 
extra permissions then the sandbox model won't nag at all.

If you want to redesign years of study put into the linux emulator, its 
permissions, and its protection levels, to make-up your own homebrew 
sandbox, then go right ahead and worry about remote execution.

Argent Stonecutter wrote:
> On 2010-03-17, at 14:14, Dzonatas Sol wrote:
>> It's still the same concept: to download and install...  they are 
>> overused buzzwords that make people think there are some elaborate 
>> separations for the basic ideas on how to migrate processes.
>
> That's because there are. One requires a human in the loop to decide 
> "I'm going to deliberately choose to trust this piece of code". Not 
> just "approve" it, but to actively seek it out and pull it in. The 
> other allows drive-by attacks at the speed of broadband.
>
> It's the difference between an automated remote execution attack and a 
> social engineering attack.
>

___
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 REST/HTTP doc sample

[Dzonatas Sol]

Thank you. I've tried to keep it simple and minimal for everybody.

For example:

$ wget http://localhost:50140/Agent/Groups

...

etc

Earlier today I considered a way to keep a passive connection open, so 
that one can easily access the viewer from shell scripts. It's not hard 
for me to re-enable so one can do as you request. It would be simple to 
add a controlgroup variable to either require an "/Interface/Connect" 
method performed or not. The "/Interface/Connect" method is there to 
enable a simple secure session, yet easy to disable for tests or to 
access the raw HTTP from tools like wget. The "/Interface/Connect" sets 
a cookie for the session and tries to establish an active socket between 
the viewer and script. I have already planned to eventually remove the 
active socket and only have the passive http interface. I'll post more 
unix shell script samples when this is done.


Brent Tubbs wrote:
> That looks very neat!
>
> SNOW-375 talks a lot about the MonoVida viewer, but I don't see any 
> mention of that in your email below. �Is MonoVida needed to try this 
> out? �I'm interested in just poking at the REST interface a bit with 
> some raw http.
>
> I'll see if Opensource Obscure's build instructions on that page still 
> work. �If I can get the latest SG + this patch working, I'd be 
> interested in helping to develop this further.
>
> Brent
>
> On Wed, Mar 17, 2010 at 10:21 AM, Dzonatas Sol  <mailto:dzona...@gmail.com>> wrote:
>
> Here is a sample of the REST/HTTP doc for SNOW-375.
>
> SNOW-375 adds a HTTP server in the viewer to be easily accessible
> by any
> process or client-side script in a language agnostic manner.
>
> I posted this here to hopefully encourage forward movement in
> client-side scripting and to avoid the backpedal and reinventions.
>
> Note: This is tried, tested, and works. This is not just "talk" or
> made-up documentation.
>
> +
>
> SNOW-375: REST/HTTP URI patterns and response summary as of March 2010
>
> All names that appears in angle brackets, <>, are variable.
>
> Note full URI paths used, yet these don't include the
> "http://host:port/"; designation.
>
> Example URI: http://localhost:50140/ControlGroup/SavedSettings
>
> All responses are wrapped in LLSD (examples not included in this doc).
>
> Most of these use the GET method, and combined/burst throughput
> via the
> POST method.
>
> 
> /ControlGroup
>
> Response is a list of control groups.
>
>
> 
> /ControlGroup/
>
> Response is a list of valid variables in a controlgroup with default
> settings
>
>  is currently either "SavedSettings" or
> "SavedPerAccountSettings"
>
>
> 
> /ControlGroup//
>
> Response is a detailed and update of current settings for the specific
> variable identified.
>
>  is currently either "SavedSettings" or
> "SavedPerAccountSettings"
>  is a valid variable name from one of the variable control
> groups.
>
>
> 
> /Agent/Groups
>
> Response is a list with details of groups joined by the connected
> agent.
>
>
> 
> /AvatarTracker/Friends
>
> Response is the UUID list of the agent's friends and basic status
> of each.
>
>
> 
> /AvatarTracker/Friend/
>
> Response is a detailed relationship information for a specified
> friend UUID.
>
>
> 
> /GestureManager/Items
>
> Response is a list of UUID of active gestures.
>
>
> 
> /GestureManager/Item/
>
> Response is the details of a MultiGesture structure for the UUID
> specified.
>
>
> 
> /Inventory/Item/
>
> Response is the details of an inventory item specified by the UUID.
>
>
> 
> /Inventory/Root
>
> Response is the UUID of the root inventory folder.
>
>
> 
> /Inventory/Category/
>
> Response is the UUIDs of the descendant categories and items of the
> specified UUID.
>
>
> 
> /Asset/Notecard/
>
> Response is the notecard item specified by UUID converted to XML
> format
> (rather th

Re: [opensource-dev] Known details of LL 'Firefly' client-side scripting

[Dzonatas Sol]

Some of us are not lost in abstractions upon abstraction upon 
abstraction upon turtles.

Your welcome to try to explain in detail what you think the nature of 
the problem is devoid of such turtles.

Argent Stonecutter wrote:
> I believe you are fundamentally misunderstanding the nature of the 
> 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

Re: [opensource-dev] Known details of LL 'Firefly' client-side scripting

[Dzonatas Sol]

Morgaine wrote:
> Argent is exactly right.

The point is already made on a different level. There was no need for 
Argent to dismiss a view of it and try to push me as if I misunderstood it.

My viewpoint was from the use of and application of a sandbox model. My 
point being there is no need to reinvent the wheel on sandbox models.

You install a program natively, install it to a sandbox, or allow it to 
migrate from one process to another process on any machine, the 
difference didn't matter with the significance of the sandbox model.

>
> 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.
This is why I pointed to the sandbox model with the tried and proven 
virtualization means of linux emulation as an example. One can easily 
allow untrusted code to execute natively in the linux emulation. Bare 
bones concepts that have been developed by tons of people across the net 
without the abstractions of other sandbox models. *This we should not 
ignore*

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

Let's say BLIZZARD decided to release a software download inside of SL. 
You can use L$ to buy your next game of BLIZZARD directly inside SL. You 
go in-world, go to the shop, purchase, download, install, etc. To make 
the best use of the hardware, you'll need no abstractions upon turtles 
to slow down the 3D ability of the BLIZZARD game. This is the level of 
non-abstraction that needs to be kept in mind or else expect less.

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

If people want to wait-for and allow a LL special sandbox to run 
anything LL wants to migrate to the client-side to process off their 
servers, then pay no attention to the points I made above.
___
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

[Dzonatas Sol]

Argent Stonecutter wrote:
> On 2010-03-17, at 16:06, Dzonatas Sol wrote:
>> This is why I pointed to the sandbox model with the tried and proven 
>> virtualization means of linux emulation as an example. One can easily 
>> allow untrusted code to execute natively in the linux emulation.
>
> No you can't. Even in a virtual machine, badly behaved code can 
> compromise you. If you allow it access to resources in Second Life, it 
> can attack those resources. If you allow it to interact with your view 
> of the world, it can substitute elements displayed in that view. If 
> you allow it to make network connections, it can take part in a 
> botnet. If you run other code in that sandbox (other untrusted code 
> from a different source) it can compromise that. If you create a 
> separate VM for each piece of code, then the overhead of your 
> sandboxes becomes unmanageable. You can't just say "it's in a sandbox".
>
>> Let's say BLIZZARD decided to release a software download inside of 
>> SL. You can use L$ to buy your next game of BLIZZARD directly inside SL.
>
> If that involves downloading a file to disk and explicitly making a 
> deliberate decision to open and install that file, fine. If it 
> involves a scripted vendor being able to download and install native 
> code through an API in some sandbox in the viewer, no, that would be 
> bad. Because if BLIZZARD can use that API, then so can the PN and 
> W-Hat and SomethingAwful.
>

What you said above has completely shown discriminatory social 
engineering of who to trust. It doesn't matter, like I said, the level 
of abstraction, and you reiterated that on your own level of your own 
viewpoint. You proved your argument against my points as completely moot.

My point is to minimize the levels of abstraction and see it from that 
viewpoint without the abstraction turtles.

If you still don't understand this, then compare a sandbox, any sandbox 
model of trusted/untrusted code, to a virtual machine. For some reason, 
you either think it is complex or you wanted to make it more complex 
than that.

Somewhere along the line Argent, you trusted to install the SL binary 
and its "badly behaved code can compromise you." Don't complain to me 
and others that want to improve user security. It seems like you want to 
parade about *spooky* ideas as if we want to make it worse.

No we don't want to make it worse. Again, re-read the threads from a 
half-year to a year ago about methods to secure and trust these scripts, 
like how to "sign-off" on them, and how to take advantage of security 
models.
___
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

[Dzonatas Sol]

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.  

Please, go ahead and benchmark how SNOW-375 has added such bulk and 
processor load. There is actual code there that works, so no need to 
speculate against HTTP methods for client-side scripts.


 > I therefore suggest C++ Dynamic Shared Objects

We've been through that route. See earlier releases of MonoVida which 
didn't use any HTTP interface. Main problem: asynchronization.

Anything added directly to the viewer requires it to be in the main loop 
for synchronization of locks and access to its memory. More scripts 
added directly to that loop only slow down the entire frame rate more. 
The main issue has been that the network, renderer, UI, and other parts 
don't run asynchronously from each other. They are all in one big loop 
-- a single frame each round-trip.

Multiple processes allow us to take advantage of multi-core machines 
easier. A single loop doesn't allow us to take advantage of multi-core.
___
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

[Dzonatas Sol]

We can, for example, easily say that we don't trust your LSL code from 
your sim to run in my sim. No difference.

Some suggest the script must be "in the clear" (as in not compiled). Ok, 
I argued for that last year, yet here is agruments against it? Or, 
people want binaries? Or, people really don't understand this whole 
enigma now. (Or, people just take sides to just to take sides and to 
argue just to argue. *rollseyes*)

Given the example of the sim to sim situation of rather if the script 
should be transferred by human readable code or binary... start there. 
Think of the sim as the sandbox.

Then... move that sandbox to the client-side. Just got to put it in the 
obvious viewpoint.

OpenSim thinks firefly is a trollish topic. Go figure!

Jesse Barnett wrote:
> Sorry but I have to agree with Argent on this one.
>
> I use a sandbox all of the time for testing code and programs.
>
> The whole point of and inherent safety in a sandbox is that everything 
> is contained within. If any code is allowed to interact with anything 
> outside of the sandbox then it is NOT a sandbox.
>
> Jesse Barnett
>
> On Wed, Mar 17, 2010 at 5:46 PM, Argent Stonecutter 
> mailto:secret.arg...@gmail.com>> wrote:
>
> On 2010-03-17, at 16:55, Dzonatas Sol wrote:
> > Somewhere along the line Argent, you trusted to install the SL
> > binary and its "badly behaved code can compromise you."
>
> The SL binary does not contain a mechanism to automatically download
> and execute untrusted code from in-world content.
>
> > Don't complain to me and others that want to improve user security.
> > It seems like you want to parade about *spooky* ideas as if we want
> > to make it worse.
>
> Adding the ability to download and execute untrusted code from in-
> world content is a significant decrease in security.
>
> > No we don't want to make it worse. Again, re-read the threads from a
> > half-year to a year ago about methods to secure and trust these
> > scripts, like how to "sign-off" on them, and how to take advantage
> > of security models.
>
>
> I have been dealing with such security models professionally since the
> '90s. They are inherently hazardous. They have been used as the basis
> of far too many compromises to consider trusting them.
> ___
> 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 REST/HTTP doc sample

[Dzonatas Sol]

WGET is part of linux. It should also be available on Windows: 
http://gnuwin32.sourceforge.net/packages/wget.htm

To compile, you can try these instructions: 
http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/Communicator

It compiles on Windows, but I don't distribute a binary -- just the patch.


Nexii Malthus wrote:
> ..Except they seem to be instructions for a command-line operating 
> system? ?_?
>
> - Nexii
>
> On Thu, Mar 18, 2010 at 12:04 AM, Nexii Malthus  <mailto:nex...@googlemail.com>> wrote:
>
> Very cool Dzonatas!
>
> Now If only I could get snowglobe to compile, I'll try out
> OpenSource Obscure's build instructions as well.
>
>     - Nexii
>
>
> On Wed, Mar 17, 2010 at 7:58 PM, Dzonatas Sol  <mailto:dzona...@gmail.com>> wrote:
>
> Thank you. I've tried to keep it simple and minimal for everybody.
>
> For example:
>
> $ wget http://localhost:50140/Agent/Groups
>
> ...
>
> etc
>
> Earlier today I considered a way to keep a passive connection
> open, so
> that one can easily access the viewer from shell scripts. It's
> not hard
> for me to re-enable so one can do as you request. It would be
> simple to
> add a controlgroup variable to either require an
> "/Interface/Connect"
> method performed or not. The "/Interface/Connect" method is
> there to
> enable a simple secure session, yet easy to disable for tests
> or to
> access the raw HTTP from tools like wget. The
> "/Interface/Connect" sets
> a cookie for the session and tries to establish an active
> socket between
> the viewer and script. I have already planned to eventually
> remove the
> active socket and only have the passive http interface. I'll
> post more
> unix shell script samples when this is done.
>
>
> Brent Tubbs wrote:
> > That looks very neat!
> >
> > SNOW-375 talks a lot about the MonoVida viewer, but I don't
> see any
> > mention of that in your email below. �Is MonoVida needed to
> try this
> > out? �I'm interested in just poking at the REST interface a
> bit with
> > some raw http.
> >
> > I'll see if Opensource Obscure's build instructions on that
> page still
> > work. �If I can get the latest SG + this patch working, I'd be
> > interested in helping to develop this further.
> >
> > Brent
> >
> > On Wed, Mar 17, 2010 at 10:21 AM, Dzonatas Sol
> mailto:dzona...@gmail.com>
> > <mailto:dzona...@gmail.com <mailto:dzona...@gmail.com>>> wrote:
> >
> > Here is a sample of the REST/HTTP doc for SNOW-375.
> >
> > SNOW-375 adds a HTTP server in the viewer to be easily
> accessible
> > by any
> > process or client-side script in a language agnostic manner.
> >
> > I posted this here to hopefully encourage forward
> movement in
> > client-side scripting and to avoid the backpedal and
> reinventions.
> >
> > Note: This is tried, tested, and works. This is not just
> "talk" or
> > made-up documentation.
> >
> > +
> >
> > SNOW-375: REST/HTTP URI patterns and response summary as
> of March 2010
> >
> > All names that appears in angle brackets, <>, are variable.
> >
> > Note full URI paths used, yet these don't include the
> > "http://host:port/"; designation.
> >
> > Example URI:
> http://localhost:50140/ControlGroup/SavedSettings
> >
> > All responses are wrapped in LLSD (examples not included
> in this doc).
> >
> > Most of these use the GET method, and combined/burst
> throughput
> > via the
> > POST method.
> >
> > 
> > /ControlGroup
> >
> > Response is a list of control groups.
> >
> >
> > 
&

Re: [opensource-dev] Client-side scripting REST/HTTP doc sample

[Dzonatas Sol]

It's an architectural style to allow programs to communicate with 
stateless packets, internally or externally. For example, an HTTP 
client/server is a logical implementation of a REST design.

Unlike the SOAP style, methods are uniform and resources follow a pattern.

Please review the dissertation that covers it all in detail:
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm


Carlo Wood wrote:
> Heyas Dzonatas,
>
> nice work. I think this approach needs serious consideration.
> Perhaps you can be so friendly as to explain to the list
> what defines REST, and why this approach is a RESTfull
> implementation?
>
> On Wed, Mar 17, 2010 at 10:21:06AM -0700, Dzonatas Sol wrote:
>   
>> Here is a sample of the REST/HTTP doc for SNOW-375.
>>
>> SNOW-375 adds a HTTP server in the viewer to be easily accessible by any 
>> process or client-side script in a language agnostic manner.
>>
>> I posted this here to hopefully encourage forward movement in 
>> client-side scripting and to avoid the backpedal and reinventions.
>>
>> Note: This is tried, tested, and works. This is not just "talk" or 
>> made-up documentation.
>>
>> +
>>
>> SNOW-375: REST/HTTP URI patterns and response summary as of March 2010
>>
>> All names that appears in angle brackets, <>, are variable.
>>
>> Note full URI paths used, yet these don't include the 
>> "http://host:port/"; designation.
>>
>> Example URI: http://localhost:50140/ControlGroup/SavedSettings
>>
>> All responses are wrapped in LLSD (examples not included in this doc).
>>
>> Most of these use the GET method, and combined/burst throughput via the 
>> POST method.
>>
>> 
>> /ControlGroup
>>
>> Response is a list of control groups.
>>
>>
>> 
>> /ControlGroup/
>>
>> Response is a list of valid variables in a controlgroup with default 
>> settings
>>
>>  is currently either "SavedSettings" or "SavedPerAccountSettings"
>>
>>
>> 
>> /ControlGroup//
>>
>> Response is a detailed and update of current settings for the specific 
>> variable identified.
>>
>>  is currently either "SavedSettings" or "SavedPerAccountSettings"
>>  is a valid variable name from one of the variable control 
>> groups.
>>
>>
>> 
>> /Agent/Groups
>>
>> Response is a list with details of groups joined by the connected agent.
>>
>>
>> 
>> /AvatarTracker/Friends
>>
>> Response is the UUID list of the agent's friends and basic status of each.
>>
>>
>> 
>> /AvatarTracker/Friend/
>>
>> Response is a detailed relationship information for a specified friend UUID.
>>
>>
>> 
>> /GestureManager/Items
>>
>> Response is a list of UUID of active gestures.
>>
>>
>> 
>> /GestureManager/Item/
>>
>> Response is the details of a MultiGesture structure for the UUID specified.
>>
>>
>> 
>> /Inventory/Item/
>>
>> Response is the details of an inventory item specified by the UUID.
>>
>>
>> 
>> /Inventory/Root
>>
>> Response is the UUID of the root inventory folder.
>>
>>
>> 
>> /Inventory/Category/
>>
>> Response is the UUIDs of the descendant categories and items of the 
>> specified UUID.
>>
>>
>> 
>> /Asset/Notecard/
>>
>> Response is the notecard item specified by UUID converted to XML format 
>> (rather than 'linden notecard format').
>>
>> 
>> /Interface/Connect
>>
>> POST: Attempt to negotiate a connection to enable the above resources.
>> * Details of connection steps not included in this doc.
>>
>> 
>> /AvatarTracker/Friend/s
>> /GestureManager/Item/s
>> /Inventory/Item/s
>> /Inventory/Category/s
>>
>> POST: List of UUIDs for combined query, as above where  is replace 
>> with just an "s".
>> Response: List of combined queries as if each item is an individual 
>> responses to each UUID.
>> 
>
>   

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

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

[opensource-dev] Snowglobe Mecurial Repository

[Dzonatas Sol]

At the Open Source meet today, it appears we have a light at the end of 
the tunnel for the SVN repository, so we need volunteers, eventually, to 
help manage the hg repository.

Here is the hg site for linden lab: http://bitbucket.org/lindenlab/

To help clarify the movement, the oss-viewer branch in the svn 
repository is the export from Linden Lab's internal branch. It appears 
there was no disagreement to let that process be automated as much as 
possible.

The snowglobe-1.3, snowglobe-1.4 and snowglobe-2 branches in the svn 
repository are now the interim solution to continue merges on snowglobe. 
If there is no resistance, then most of what is in oss-viewer can be 
easily merged over to svn snowglobe-1.x branches (either 1.4 or v2)

To help quicken the merges and to save the history of them, we need 
volunteers on to help with the hg repository. The snowglobe-1.x branches 
can migrate over the hg on bitbucket.org.

With the above knowledge, this is to help minimize the maintenance to 
has been needed in order to merge the svn way.

I think a question would be is if we want, as a community, to start with 
snowglobe 1.4 or snowglobe 2.0 as the master hg repository on bitbucket.

The transcript can be located here (when available): 
https://wiki.secondlife.com/wiki/Open_Source_Meeting



___
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 Mecurial Repository

[Dzonatas Sol]

Latif Khalifa wrote:
> On Fri, Mar 19, 2010 at 12:58 AM, Dzonatas Sol  wrote:
> [snip]
>   
>> At the Open Source meet today, it appears we have a light at the end of
>> To help quicken the merges and to save the history of them, we need
>> volunteers on to help with the hg repository. The snowglobe-1.x branches
>> can migrate over the hg on bitbucket.org.
>> 
>
> I think you misunderstood what was said. The people who could
> eventually be helping Merov with changes are those that are already
> committers to snowglobe. Also the oss-viewer and snowglobe branches
> are in the public linden svn.
>
>   
It's not what I misunderstand, yet it is what we need to clarify to help 
move forward.

These volunteers don't magically appears and we can't expect these task 
magically get done.

It's already been said awhile ago the move away from svn, yet there was 
no weight upon it until now.

I don't think the svn-committers want to touch the oss-viewer branch, 
yet don't mind if the snowglobe branch remains open to commit. It would 
be the wrong impression, further, to assume the same committers will 
take on the extra load to help move to hg.

___
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 Mecurial Repository

[Dzonatas Sol]

Cool intro!

Here is a rosetta stone to add, for those use to git to help understand hg:

http://wiki.sympy.org/wiki/Git_hg_rosetta_stone#Rosetta_Stone


Brent Tubbs wrote:
> Yes hg (mercurial) is distributed. �It also thinks in terms of 
> "changesets" rather than "versions".
>
> Joel Spolsky of the Joel on Software blog just did a very nice intro 
> and tutorial on Mercurial that you can read at http:///hginit.com 
> <http://hginit.com> . �The first section in particular highlights the 
> differences between Mercurial and Subversion.
>
> Brent
>
> On Fri, Mar 19, 2010 at 5:19 AM, Jonathan Irvin  <mailto:djfoxys...@gmail.com>> wrote:
>
> If I'm not mistaken, Hg is distributed like Git.
>
> Jonathan Irvin
>
>
>
> On Fri, Mar 19, 2010 at 05:12, Carlo Wood  <mailto:ca...@alinoe.com>> wrote:
>
> What is the advantage again of hg (over svn)? (why the move)
>
> On Thu, Mar 18, 2010 at 05:18:54PM -0700, Dzonatas Sol wrote:
> > � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
> � �It would
> > be the wrong impression, further, to assume the same
> committers will
> > take on the extra load to help move to hg.
>
> --
> Carlo Wood mailto:ca...@alinoe.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
>
>
> 
>
> ___
> 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 Mecurial Repository

[Dzonatas Sol]

For one, http://hgbook.red-bean.com/

Bryan O'Sullivan has worked at LL, so there is the obvious uptake there 
with his work on hg.

Yes, the greater community has used git, yet the main point is we need 
to expire svn in order to help maintain merges easier and in a more 
distributed fashion. LL uses hg internally.


Ron Festa wrote:
> Then why Hg over Git?
>
> Ron Festa
> Virtual Worlds Admin
> Division of Continuing Studies at Rutgers University
> PGP key: http://bit.ly/b1ZyhY
> Phone: 732-474-8583
>
>
> On Fri, Mar 19, 2010 at 8:19 AM, Jonathan Irvin  <mailto:djfoxys...@gmail.com>> wrote:
>
> If I'm not mistaken, Hg is distributed like Git.
>
> Jonathan Irvin
>
>
>
> On Fri, Mar 19, 2010 at 05:12, Carlo Wood  <mailto:ca...@alinoe.com>> wrote:
>
> What is the advantage again of hg (over svn)? (why the move)
>
> On Thu, Mar 18, 2010 at 05:18:54PM -0700, Dzonatas Sol wrote:
> > � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
> � �It would
> > be the wrong impression, further, to assume the same
> committers will
> > take on the extra load to help move to hg.
>
> --
> Carlo Wood mailto:ca...@alinoe.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
>
>
> 
>
> ___
> 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

[Dzonatas Sol]

To help understand this:

If we use the analogy sense of "eye for an eye" but only as in 'GPL for 
a GPL,' then contributors should be able to submit GPL based patches to 
the GPL source. However, that is not the case when a GPL for a GPL also 
require a Contribution Agreement. Sure, there are other companies that 
have such, yet just because they do doesn't justify anything more here 
to require such. Just ask for the one who submits the GPL based patched 
to assign the patch over to Linden Lab or FSF, and the extra weight is 
consolidated.

Here is where we can draw the line beyond that. Everything that requires 
the Contributors Agreement (beyond the above) is obviously being 
questioned by the community (and even by LL employees).

These thread is evident of what is on this other side of the line that 
isn't plain 'GPL for a GPL.'


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] Moving forward with open development

[Dzonatas Sol]

Ambroff Linden wrote:
>
> 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

Yes, a simple copyright assignment would be easier then a Contributor 
Agreement:

1) Programmer A submits a patch under GPL to the GPL source.
2) Programmer A makes sure patch is copyrighted by LL (copyright 
assignment done).
3) LL applies patch and continues to distribute as usual by GPL.

Keep It Simple.

___
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] 32 bit Official viewer 2 beta, Snowglobe binary (rev 3229) does't run 'out of the box'

[Dzonatas Sol]

For awhile, I was able to download the Snowglobe binary and run it on my 
Debian Lenny system. Now this didn't work with the latest Official 
release binary and snowglobe binary.

Actually, it's the included 32 bit libraries themselves that cause a 
problem which gives an assertion failure when started. It's either libc6 
or libopenal, or maybe another. (not easy to pinpoint without full trace)

If I run the binary distribution on Debian Sid, it starts fine with no 
binary release. However, it's not practical to require us to use Debian 
Sid to run a binary, as that means the release has inherited 
'unstable'-ness.

My guess is someone must have re-compiled the 32 bit libs under Sid 
instead of under Lenny (or Etch). That would then have mess up the 
dependencies and cause the assertion failure above.

Debian Sid did recently upgrade it's libc6 (and c++ versions) from 4.3 
to 4.4.


Can LL please fix/double-check the 32 bit libs (linked and dso) of the 
32 bit Official viewer 2 beta and Snowglobe binaries, so that they work 
under 32 bit Lenny without assertion failures.


___
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

[Dzonatas Sol]

Nyx Linden wrote:
> 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!).
>   

All these features could be contained in an app or client-side script 
outside the main viewer. This is one of the reasons why I wanted to 
develop SNOW-375: https://jira.secondlife.com/browse/SNOW-375

This new "detailed" appearance UI doesn't need to be in the viewer at 
all. The basic Inventory UI can stay built-in to the viewer in order to 
provide default functionality.

I recently added methods to access inventory items through the REST/HTTP 
interface. I don't want to spill all details at this time, yet 
scriptable access to the inventory could, for example, read a notecard 
that then reads all the layered composites (texture UUIDs) to bake on 
the avatar. Then the script does a POST or PUT with the final composite 
to trigger the baked upload.

I'd probably be done with such a UI if my disability didn't slow me down. =(

Anyways, do look at these galleries carefully to notice the level of 
detail for avatars that I have kept in mind:

http://igolochka.deviantart.com/gallery/

http://opalseadragon.deviantart.com/gallery/

Things to note off hand:
1) level of detail to the composite skin layers and immediate clothes layer
2) level of detail of the physics of the clothes how (they pass over the 
skin and not through the skin)
3) level of detail of the fingers and toes, and close-ups of facial features

The main renderer of the viewer may not include such detail because of 
practicality of speed, yet when someone examines a person's profile, 
then these kinds of details could be rendered.

A "snapshot" could also become much more higher quality if the rest of 
these details were filled in just for the pose.
___
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] 32 bit Official viewer 2 beta, Snowglobe binary (rev 3229) does't run 'out of the box'

[Dzonatas Sol]

Carlo Wood wrote:
> What is the assertion failure?
>
>   

This is the error right after one types in "./snowglobe" or 
"./secondlife" to run the startup script:
Inconsistency detected by ld.so: dl-open.c: 643: _dl_open: Assertion 
`_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!

Note that libwrap does exist in lenny or squeeze, only in etch and sid: 
http://packages.debian.org/etch/libwrap-dev


With "LD_DEBUG=versions", here is part of the output:

 19683:   
 19683:   
 19683:calling init: 
/home/dzonatas/Desktop/S/Snowglobe-i686-1.4.0.0/lib/libopenal.so.1
 19683:   
Inconsistency detected by ld.so: dl-open.c: 643: _dl_open: Assertion 
`_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!
*** Bad shutdown. ***
 19684:checking for version `GLIBC_2.3' in file /lib/libc.so.6 
[0] required by file uname [0]
 19684:checking for version `GLIBC_2.2.5' in file /lib/libc.so.6 
[0] required by file uname [0]
 19684:checking for version `GLIBC_PRIVATE' in file 
/lib64/ld-linux-x86-64.so.2 [0] required by file /lib/libc.so.6 [0]
 19684:checking for version `GLIBC_2.3' in file 
/lib64/ld-linux-x86-64.so.2 [0] required by file /lib/libc.so.6 [0]
 19684:   
 19684:calling init: /lib/libc.so.6
 


With "LD-DEBUG=versions,libs", here is part of the output:


 19583: 
 19583:find library=libwrap.so.0 [0]; searching
 19583: search 
path=/home/dzonatas/Desktop/S/Snowglobe-i686-1.4.0.0/lib:tls/i686/sse2/cmov:tls/i686/sse2:tls/i686/cmov:tls/i686:tls/sse2/cmov:tls/sse2:tls/cmov:tls:i686/sse2/cmov:i686/sse2:i686/cmov:i686:sse2/cmov:sse2:cmov:

(LD_LIBRARY_PATH)
 19583:  trying 
file=/home/dzonatas/Desktop/S/Snowglobe-i686-1.4.0.0/lib/libwrap.so.0
 19583:  trying file=tls/i686/sse2/cmov/libwrap.so.0
 19583:  trying file=tls/i686/sse2/libwrap.so.0
 19583:  trying file=tls/i686/cmov/libwrap.so.0
 19583:  trying file=tls/i686/libwrap.so.0
 19583:  trying file=tls/sse2/cmov/libwrap.so.0
 19583:  trying file=tls/sse2/libwrap.so.0
 19583:  trying file=tls/cmov/libwrap.so.0
 19583:  trying file=tls/libwrap.so.0
 19583:  trying file=i686/sse2/cmov/libwrap.so.0
 19583:  trying file=i686/sse2/libwrap.so.0
 19583:  trying file=i686/cmov/libwrap.so.0
 19583:  trying file=i686/libwrap.so.0
 19583:  trying file=sse2/cmov/libwrap.so.0
 19583:  trying file=sse2/libwrap.so.0
 19583:  trying file=cmov/libwrap.so.0
 19583:  trying file=libwrap.so.0
 19583: search cache=/etc/ld.so.cache
 19583: search 
path=/lib32/tls/i686/sse2/cmov:/lib32/tls/i686/sse2:/lib32/tls/i686/cmov:/lib32/tls/i686:/lib32/tls/sse2/cmov:/lib32/tls/sse2:/lib32/tls/cmov:/lib32/tls:/lib32/i686/sse2/cmov:/lib32/i686/sse2:/lib32/i686/cmov:/lib32/i686:/lib32/sse2/cmov:/lib32/sse2:/lib32/cmov:/lib32:/usr/lib32/tls/i686/sse2/cmov:/usr/lib32/tls/i686/sse2:/usr/lib32/tls/i686/cmov:/usr/lib32/tls/i686:/usr/lib32/tls/sse2/cmov:/usr/lib32/tls/sse2:/usr/lib32/tls/cmov:/usr/lib32/tls:/usr/lib32/i686/sse2/cmov:/usr/lib32/i686/sse2:/usr/lib32/i686/cmov:/usr/lib32/i686:/usr/lib32/sse2/cmov:/usr/lib32/sse2:/usr/lib32/cmov:/usr/lib32:/lib/i486-linux-gnu/tls/i686/sse2/cmov:/lib/i486-linux-gnu/tls/i686/sse2:/lib/i486-linux-gnu/tls/i686/cmov:/lib/i486-linux-gnu/tls/i686:/lib/i486-linux-gnu/tls/sse2/cmov:/lib/i486-linux-gnu/tls/sse2:/lib/i486-linux-gnu/tls/cmov:/lib/i486-linux-gnu/tls:/lib/i486-linux-gnu/i686/sse2/cmov:/lib/i486-linux-gnu/i686/sse2:/lib/i486-linux-gnu/i686/cmov:/lib/i486-linux-gnu/i686:/lib/i486-linux-gnu/sse2/cmov:/lib/i486-linux-gnu/sse2:/lib/i486-linux-gnu/cmov:/lib/i486-linux-gnu:/usr/lib/i486-linux-gnu/tls/i686/sse2/cmov:/usr/lib/i486-linux-gnu/tls/i686/sse2:/usr/lib/i486-linux-gnu/tls/i686/cmov:/usr/lib/i486-linux-gnu/tls/i686:/usr/lib/i486-linux-gnu/tls/sse2/cmov:/usr/lib/i486-linux-gnu/tls/sse2:/usr/lib/i486-linux-gnu/tls/cmov:/usr/lib/i486-linux-gnu/tls:/usr/lib/i486-linux-gnu/i686/sse2/cmov:/usr/lib/i486-linux-gnu/i686/sse2:/usr/lib/i486-linux-gnu/i686/cmov:/usr/lib/i486-linux-gnu/i686:/usr/lib/i486-linux-gnu/sse2/cmov:/usr/lib/i486-linux-gnu/sse2:/usr/lib/i486-linux-gnu/cmov:/usr/lib/i486-linux-gnu

(system search path)
 19583:  trying file=/lib32/tls/i686/sse2/cmov/libwrap.so.0
 19583:  trying file=/lib32/tls/i686/sse2/libwrap.so.0
 19583:  trying file=/lib32/tls/i686/cmov/libwrap.so.0
 19583:  trying file=/lib32/tls/i686/libwrap.so.0
 19583:  trying file=/lib32/tls/sse2/cmov/libwrap.so.0
 19583:  trying file=/lib32/tls/sse2/libwrap.so.0
 19583:  trying file=/lib32/tls/cmov/libwrap.so.0
 19583:  trying file=/lib32/tls/libwrap.so.0
 19583:  trying file=/lib32/i686/sse2/cmov/libwrap.so.0
 19583:  trying file=/lib32/i686/sse2/libw

Re: [opensource-dev] 32 bit Official viewer 2 beta, Snowglobe binary (rev 3229) does't run 'out of the box'

[Dzonatas Sol]

I found a workable solution.

$ mkdir /tmp/extralibs
$ wget 
http://ftp.us.debian.org/debian/pool/main/g/gdbm/libgdbm3_1.8.3-3_i386.deb
$ wget 
http://ftp.us.debian.org/debian/pool/main/t/tcp-wrappers/libwrap0_7.6.q-16_i386.deb
$ dpkg -x libgdbm3_1.8.3-3_i386.deb /tmp/extralibs
$ dpkg -x libwrap0_7.6.q-16_i386.deb /tmp/extralibs
$ cd YOURSNOWGLOBEDIR
$ cp /tmp/extralibs/lib/* lib
$ cp /tmp/extralibs/usr/lib/* lib

32 bit Snowglobe 1.4+ binaries then work on Debian Lenny 64

Carlo Wood wrote:
> That is the same error as one gets with (32bit) skype
> when running it on 64bit debian. The work around there
> is to make the audiopulse libs unreadable (chmod -r)
> so that they are skipped.
>
> It smells like an OS bug because it seems related to
> 64bit systems only? Ie, a lib32* package needs a fix?
>
>   

___
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] [META] Communication tools

[Dzonatas Sol]

Boroondas Gupte wrote:
> On 03/23/2010 06:12 AM, Philippe (Merov) Bossut wrote:
>> - Mailing list: may be the most widely used tool. The problem I see 
>> with it is that it mixes everything: small requests, long 
>> discussions, policies, technicalities, etc... Other FLOSS projects 
>> use a variety of lists, breaking things in categories (Mozilla for 
>> instance). It tends to become another kind of mess with cross posting.
>> Yes, Gmail rocks and threaded discussions a god send but still...
> Thunderbird isn't bad for it, either. I guess other sufficently 
> advaned email clients work similarly well.
>

Thunderbird is whole reason why to keep discussions on a mail-list. The 
web-based forums (or gmail) just don't compare with the versatility, 
accessibility, and speed of Thunderbird.

I do agree both the web-based forums and mail-list should be used at 
their fullest. I think the more technical content discussions should be 
kept to the mail-list and policy based discussions can be moved to the 
web-forums.

___
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] 32 bit Official viewer 2 beta, Snowglobe binary (rev 3229) does't run 'out of the box'

[Dzonatas Sol]

Robin Cornelius wrote:
> On Tue, Mar 23, 2010 at 3:36 PM, Dzonatas Sol  wrote:
>   
>> I found a workable solution.
>>
>> $ mkdir /tmp/extralibs
>> $ wget
>> http://ftp.us.debian.org/debian/pool/main/g/gdbm/libgdbm3_1.8.3-3_i386.deb
>> $ wget
>> http://ftp.us.debian.org/debian/pool/main/t/tcp-wrappers/libwrap0_7.6.q-16_i386.deb
>> $ dpkg -x libgdbm3_1.8.3-3_i386.deb /tmp/extralibs
>> $ dpkg -x libwrap0_7.6.q-16_i386.deb /tmp/extralibs
>> $ cd YOURSNOWGLOBEDIR
>> $ cp /tmp/extralibs/lib/* lib
>> $ cp /tmp/extralibs/usr/lib/* lib
>>
>> 32 bit Snowglobe 1.4+ binaries then work on Debian Lenny 64
>> 
>
>
> Can we wiki this somewhere? would be handy to keep any compatability
> work arounds documented somewhere.
>
> Regards
>
> Robin
>
>   
Added here:

https://wiki.secondlife.com/wiki/User:Dzonatas_Sol/Snowglobe#Snowglobe_32_bit_Compatibility_on_Debian_Lenny_64

Thanks for the help and suggestions, everyone!
___
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

[Dzonatas Sol]

An easier way may just to have  list without ordinals. Example:

Outfit:
* Upper-body
** Jacket
** Shirt
** Undershirt
** upper-tattoos
** custom-upper-body-skin
** another-custom-upper-body-skin
* Lower-body
** Pants
** Underpants
** lower-tattoos
** custom-lower-body-skin
** another-custom-lower-body-skin

etc

We can just use a hierarchal like list when any number of subelements. 
The items near the top of the list appear above the other layers. This 
way specific layer numbers aren't needed (or the viewer can 
automatically compute them for you).

Just insert an item into the list and move it up and down in layer 
appearance priority.

Glen Canaday wrote:
> Actually, I don't mind "undies, shirt, and jacket." What I'm really 
> referring to is maybe 3 undies layers numbered 1,2,3. Creators can 
> still specify which of those three as they do now, but the user would 
> choose the 1, 2, 3 bit. The creator doesn't lose the ability to choose 
> which of the three upper layers (or two lower), so they can still 
> specify on which layer the items would look as intended... but the 
> user doesn't have to stick to "gee, do I wear the garter, the undies, 
> or the tattoos? But I still want to wear the glitchpants that came 
> with the skirt..."
>
> I think 1,2,3 is probably fine.. that gives 9 uppers and 6 lowers. 
> There should be a limit to keep the code simple, it's just a way 
> bigger limit!
>
> There are content creators that give transfer on items.. and I like it 
> that way. There are some (ok, one that I can name) that doesn't give 
> multiple layers because she gives them xfer, which I can understand. 
> It all comes down to smart permissions for the next person. But that's 
> a key issue for the creators I think.
>
> However, they'd still get to choose that their pants go on the pants 
> layer - just not choose WHICH pants layer. The user would get that, 
> and that might curb some people's bitching at the creators! Kind of a 
> win-win imo...
>
> --GC
>
> On 03/24/2010 09:48 PM, Brent Tubbs wrote:
>> I like this idea a lot. �While we're talking about about increasing 
>> flexibility though, why have a low hardcoded limit to the number of 
>> layers? �The new tattoo and alpha layers are great, but what comes 
>> next, and how long do we keep hardcoding more specific layers? �If 
>> someone wants to layer on ten tattoos at once, let's let them! �At 
>> some point it makes sense to throw away the pre-defined layers and 
>> just call them 1 through n.
>>
>> On the other hand, some content creators sell items in separate 
>> under-layer and tattoo friendly over-layer packs. �I imagine some of 
>> them would be pretty upset if the layer restrictions on all the 
>> products they've sold were suddenly removed.
>>
>> Brent
>>
>> On Wed, Mar 24, 2010 at 6:21 PM, Glen Canaday > > wrote:
>>
>> Nyx,
>>
>> Oh, I actually do have one functionality idea / request: rather
>> than allowing the creator to dictate the clothing layer of a
>> wearable, can we allow the wearer themselves choose where it
>> goes? I can't tell you how many times I've had to not wear
>> something because the original creator did not have the foresight
>> to put it on a layer that makes sense for that wearable, nor
>> include a copy that goes onto the desired layer.
>>
>> We might have a tattoo layer now, but most places are not
>> offering that, nor are very many people using 2.0. It would be
>> nice to be able to choose that a tattoo goes *under* the
>> underpants since most people sell tats on the unders layer and
>> will until 2.1 or 2.2 is widely used. If we get to choose which
>> of which multiple-wearable goes on top at /wear/ time and not
>> /creation/ time, it allows for far more flexibility in
>> customizing an avatar's look.
>>
>> Just my $0.02, but it's hard to justify having multiple layers in
>> my mind without doing it this way.
>>
>>
>> --GC
>>
>> On 03/23/2010 12:58 PM, Nyx Linden wrote:
>>>   The current iteration of the appearance floater needs to go away. The 
>>> current implementation has been held together with chicken wire, bubble 
>>> gum, and duct tape. It works for now, but it won't hold up to the 
>>> addition of multiple wearables of a given type. The currently designed 
>>> plan is to extend the appearance sidebar to pick up the extra 
>>> functionality of editing a saved outfit and editing of individual 
>>> wearables. I think the flow between the different stages (selecting 
>>> your 
>>> outfit, editing your outfit, editing a wearable item) should be pretty 
>>> useful and intuitive. I'll be posting our initial design thoughts once 
>>> we get the appropriate channels set up (forums most likely).
>>>
>>> I will remind you, however, that this project is specifically about 
>>> extending the avatar functionality. Yes there is a UI element here, and 
>>> I'

Re: [opensource-dev] Open Development project: extending avatar wearables

[Dzonatas Sol]

In the list I made, that would be for the wearer only -- not the creator.

There are:
(A) creators of the layers
(B) creator of the outfit list.
(C) wearer of the outfit

By default, (B) & (C) are the same -- the wearer.

(A) is able to supply a outfit list to help suggest layer order, but it 
doesn't override (C)'s outfit unless (C) specifies to completely replace 
the (C)'s outfit list with (A)'s suggested list.

If (C) only wants to "add to" outfit, then (C)'s list is merged with 
(A)'s list (C) gets a side-by-side UI of the two lists where you could 
merge by hand, drag-n-drop, etc.

There was a suggestion (from Nyx?) to use the individual item's 
description to help with the order. Maybe something like "outer" 
"middle" "inner" "skin" could be keywords left in the description to 
give a default order without a outfit list. When you add an item to the 
list, it would check for such keyword, and place it in a default order 
based on such keyword.

Glen Canaday wrote:
> That's actually what I would like to avoid, specifically. That forces 
> the creator to continue to dictate whether your underwear goes on top of 
> your pants or not. There's no added flexibility for the resident in that.
>
> Here's why I'll be an advocate of just a few extra numbered layers on 
> top of the existing system (until someone blows me away with a simpler 
> to implement, more flexible solution):
>
> Creator: no change. "Hmm... undie, pants, undershirt, shirt, jacket."
> Creator A: "... it puts the pants on pants layer"
>
> Wearer: "I got a pants layer from Creator A! ... but my tights are 
> pants, too... Oh, ok. Tights on Pants1, pants from Creator A on Pants 2. 
> That'll do it.."
>
> No change for the creator - none. Not a thing. The user gets a "bump up" 
> or "bump down" item in the current "wear" submenu.. that's all. Max 3 or 
> so, and they act like layers in Photoshop or Gimp, which is essentially 
> what they are now.
>
> Totally minimal UI change, no change in permissions, and just a few 
> extra layers to bake - half of which will usually be empty anyway until 
> people discover the coolness of wearing 3 pairs of pants at once. (last 
> part's a joke, but you get my meaning.)
>
> lower layer list:
> *skin
> *alpha
> *tattoo
> *underwear 1
> *underwear 2
> *underwear 3
> *pants 1
> *pants 2
> *pants 3
> (*jacket 1 lower)
> (*jacket 2 lower)
> (*jacket 3 lower)
>
> uppers:
> *skin
> *alpha
> *tattoo
> *undershirt 1
> *undershirt 2
> *undershirt 3
> *shirt 1
> *shirt 2
> *shirt 3
> *jacket 1 upper
> *jacket 2 upper
> *jacket 3 upper
>
> Would also be nice to have a few facial layers, too. The current tattoo 
> layer in 2.0 is full-body, one layer only. That doesn't work for people 
> who like to mix-n-match, but that in combination with the above list does.
>
> I'm still open to be convinced - I'm just starting the discussion off!
>
> --GC
>
> On 03/24/2010 10:58 PM, Dzonatas Sol wrote:
>   
>> An easier way may just to have  list without ordinals. Example:
>>
>> Outfit:
>> * Upper-body
>> ** Jacket
>> ** Shirt
>> ** Undershirt
>> ** upper-tattoos
>> ** custom-upper-body-skin
>> ** another-custom-upper-body-skin
>> * Lower-body
>> ** Pants
>> ** Underpants
>> ** lower-tattoos
>> ** custom-lower-body-skin
>> ** another-custom-lower-body-skin
>>
>> etc
>>
>> We can just use a hierarchal like list when any number of subelements. 
>> The items near the top of the list appear above the other layers. This 
>> way specific layer numbers aren't needed (or the viewer can 
>> automatically compute them for you).
>>
>> Just insert an item into the list and move it up and down in layer 
>> appearance priority.
>>
>> Glen Canaday wrote:
>> 
>>> Actually, I don't mind "undies, shirt, and jacket." What I'm really 
>>> referring to is maybe 3 undies layers numbered 1,2,3. Creators can 
>>> still specify which of those three as they do now, but the user would 
>>> choose the 1, 2, 3 bit. The creator doesn't lose the ability to 
>>> choose which of the three upper layers (or two lower), so they can 
>>> still specify on which layer the items would look as intended... but 
>>> the user doesn't have to stick to "gee, do I wear the garter, the 
>>> undies, or the tattoos? But I still want to wear the glitchpants that 
>>> came with the skirt..."
&

Re: [opensource-dev] Third party viewer policy: commencement date

[Dzonatas Sol]

It's obvious the TPV is directed at sources and distributors that do not 
conform to specifications as implemented/documented by the GPL code in 
Snowglobe.

If you implement a third-party network protocol, it probably would be of 
benefit to you to to publish how your version of the network protocol 
conforms to the implementation in Snowglobe. Look at python's own 
regression test: http://docs.python.org/library/test.html . With such a 
test, you could help guarantee to people, that use your software, that 
you took steps to handle their valuable assets without error as much as 
possible. That level of regression tests isn't being asked for in 
compliance, nor does LL seem to desire to become one to oversee such 
effort, but instead they offer the TPV.

More specifically then 'as the only people complaining are "non 
contributors"' is the appearance that those that have complained the 
most about the TPV and any suggestion that may have the question of the 
TPV at hand is those against the GPL. To say one cannot look at or use 
GPL code as reference documentation is like to say one cannot look at or 
use information from wikipedia. Instead of a GFDL/CCSA based docs, 
Snowglobe has the documentation/implementation under GPL. The practice 
to GPL code as a reference is not unique to Linden Lab.

If a third-party network protocol is intended in any way to be 
compatible with SL grid, yet the authors never compared their work to a 
reference platform like Snowglobe that has been made available, then 
users have a right to question the reliability and authenticity of the 
network protocol itself, especially if they spend their money on 
valuable assets.

Your proposed solution was to disable Naali's attempts to connect to SL 
grid, as noted here: 
http://groups.google.com/group/realxtend/browse_thread/thread/a950a62ba97c14a4

LibOMV (OpenSim) has many developers and users that have been told to 
never look at GPL code (like Snowglobe). Therefore, we can assume that 
LibOMV has never done any regression tests for compliance with the 
network protocol as documented by Snowglobe. Users should be aware of 
this fact, so they are not mistaken that LibOMV (OpenSim and any viewer 
built from LibOMV) developers have never guaranteed on any level of such 
mere compliance that steps have been taken to handle their valuable 
assets reliably.

At around US$50 million dollars a month in user transactions, is such 
compatibility and regression tests worth it?

It is very questionable why would a developer or user choose to use a 
network protocol that is has stated: "The library maintains 
compatibility with the Second Life protocol and can be used for creating 
clients and automatons in Second Life, OpenSim or other virtual worlds 
which use the Second Life Protocol." ( 
http://www.openmetaverse.org/projects/libopenmetaverse ) ... yet never 
thought it was worth to simply reference the published source as a 
measure to ensure to it's users it is compatible. How else would they 
ensure compatibility is maintained? It's OpenSim's sims policy to state 
"We cannot accept virally licensed code unless there is a specific F/OSS 
exemption for BSD-licensed projects." Therefore, we can assume OpenSim 
uses LibOMV under a guarantee to have never been referenced or derived 
from the code publish in Snowglobe.

Maybe LibOMV (OpenSim and viewers) should state the fact that in order 
them to have never looked at the GPL code that their documentation 
misrepresented compatibility with the above except. It should state 
something to the fact that the process to create LibOMV reversed 
engineered the SL grid network protocol (in order to avoid GPL?) and 
that it cannot guarantee direct compatibility with SL Grid, and that 
users of it's protocol are not guaranteed to have their assets handled 
reliably due to the fact LibOMV developers simply never looked at 
published referenced documentation.

Ryan McDougall wrote:
> I think it's pretty clear LL will broach no more discussion on this
> matter, as the only people complaining are "non contributors" -- as
> clear a statement yet that realXtend and OpenSim are not considered
> contributions to SL.
>
> As far as I'm concerned, this is a complete FUD own-goal, and
> realXtend now has a policy that developers cannot use our own viewer
> to connect to SL for any reason -- to protect us from this
> ill-conceived policy.
>
> The only people who have nothing to fear from TPV are malicious
> developers, as they were always operating outside various laws any
> way.
>
> Cheers,
>
> On Wed, Mar 24, 2010 at 6:10 PM, Morgaine
>  wrote:
>   
>> 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
>> 

Re: [opensource-dev] Open Development project: extending avatar wearables

[Dzonatas Sol]

+1 Carlo, the specific priority on animations has caused confusion of 
when to set them to 1, 2, 3, or 4. If it is not set correctly, then it 
could mess up the other animations.

I would like to see that confusion avoided with outfits.

Carlo Wood wrote:
> On an equal note, it's extremely annoying that the priority
> of animations is determined at creation time.
>
> Why can't I, as user, determine in what order I want animations
> to take precedence?
>
> On Wed, Mar 24, 2010 at 10:20:19PM -0400, Glen Canaday wrote:
>   
>> Actually, I don't mind "undies, shirt, and jacket." What I'm really referring
>> to is maybe 3 undies layers numbered 1,2,3. Creators can still specify which 
>> of
>> those three as they do now, but the user would choose the 1, 2, 3 bit. The
>> creator doesn't lose the ability to choose which of the three upper layers 
>> (or
>> two lower), so they can still specify on which layer the items would look as
>> intended... but the user doesn't have to stick to "gee, do I wear the garter,
>> the undies, or the tattoos? But I still want to wear the glitchpants that 
>> came
>> with the skirt..."
>>
>> I think 1,2,3 is probably fine.. that gives 9 uppers and 6 lowers. There 
>> should
>> be a limit to keep the code simple, it's just a way bigger limit!
>>
>> There are content creators that give transfer on items.. and I like it that
>> way. There are some (ok, one that I can name) that doesn't give multiple 
>> layers
>> because she gives them xfer, which I can understand. It all comes down to 
>> smart
>> permissions for the next person. But that's a key issue for the creators I
>> think.
>>
>> However, they'd still get to choose that their pants go on the pants layer -
>> just not choose WHICH pants layer. The user would get that, and that might 
>> curb
>> some people's bitching at the creators! Kind of a win-win imo...
>>
>> --GC
>>
>> On 03/24/2010 09:48 PM, Brent Tubbs wrote:
>>
>> I like this idea a lot.  While we're talking about about increasing
>> flexibility though, why have a low hardcoded limit to the number of 
>> layers?
>>  The new tattoo and alpha layers are great, but what comes next, and how
>> long do we keep hardcoding more specific layers?  If someone wants to 
>> layer
>> on ten tattoos at once, let's let them!  At some point it makes sense to
>> throw away the pre-defined layers and just call them 1 through n.
>>
>> On the other hand, some content creators sell items in separate 
>> under-layer
>> and tattoo friendly over-layer packs.  I imagine some of them would be
>> pretty upset if the layer restrictions on all the products they've sold
>> were suddenly removed.
>>
>> Brent
>>
>> On Wed, Mar 24, 2010 at 6:21 PM, Glen Canaday  wrote:
>>
>> Nyx,
>>
>> Oh, I actually do have one functionality idea / request: rather than
>> allowing the creator to dictate the clothing layer of a wearable, can
>> we allow the wearer themselves choose where it goes? I can't tell you
>> how many times I've had to not wear something because the original
>> creator did not have the foresight to put it on a layer that makes
>> sense for that wearable, nor include a copy that goes onto the 
>> desired
>> layer.
>>
>> We might have a tattoo layer now, but most places are not offering
>> that, nor are very many people using 2.0. It would be nice to be able
>> to choose that a tattoo goes *under* the underpants since most people
>> sell tats on the unders layer and will until 2.1 or 2.2 is widely 
>> used.
>> If we get to choose which of which multiple-wearable goes on top at
>> wear time and not creation time, it allows for far more flexibility 
>> in
>> customizing an avatar's look.
>>
>> Just my $0.02, but it's hard to justify having multiple layers in my
>> mind without doing it this way.
>>
>>
>> --GC
>>
>> On 03/23/2010 12:58 PM, Nyx Linden wrote:
>>
>>   The current iteration of the appearance floater needs to go 
>> away. The
>> current implementation has been held together with chicken wire, 
>> bubble
>> gum, and duct tape. It works for now, but it won't hold up to the
>> addition of multiple wearables of a given type. The currently 
>> designed
>> plan is to extend the appearance sidebar to pick up the extra
>> functionality of editing a saved outfit and editing of individual
>> wearables. I think the flow between the different stages 
>> (selecting your
>> outfit, editing your outfit, editing a wearable item) should be 
>> pretty
>> useful and intuitive. I'll be posting our initial design 
>> thoughts once
>> we get the appropriate channels set up (forums most likely).
>>
>> I will remind you, however, that this project is specifically 
>> about
>>  

Re: [opensource-dev] Open Development project: extendingavatar wearables

[Dzonatas Sol]

Kitty wrote:
> If someone sells a full-top + high pants combination they wouldn't have to
> struggle with defining which shirt layer goes on top of which other one by
> messing with numbers - since those will still result in conflicts with what
> it's being worn in combination with - but you just leave it up to the user.
> If they want the bottom of the top tucked into the pants then they just
> arrange the top under the pants. Or vice versa.
>
> It also solves the issue where you're limited to what the creator felt like
> providing you with and working with clothing items is much more natural than
> working with clothing layers that only clumsily map to what they represent.
>   


This is where I think a outfit list should be hierarchal  to allows 
someone to wear multiple outfit (lists).

For example, let's say this outfit list is already being "worn":

Outfit "Worn":
* Upper-body
** Shirt
** Undershirt
* Lower-body
** Underpants
** lower-tattoos

Here is another outfit list (as Kitty suggested):

Outfit "Kitty's":
* Upper-body
** full-top
* Lower-body
** high-pants


If we take Kitty's outfit and 'add to' the worn outfit (with default 
order), we get:

Outfit "Worn":
* Outfit "Kitty's":
** Upper-body
*** full-top
** Lower-body
*** high-pants
* Upper-body
** Shirt
** Undershirt
* Lower-body
** Underpants
** lower-tattoos

No priority numbers had to be given in the above lists to see that 
layers near the top of the list appear as the outer-most layers to bake. 
With the lists above, *both* the creator of the outfit and the wearer of 
the outfit have full flexibility to change the priority of the layers, 
with mod or no-mod. Keywords, like "Upper-body" slots, can appear 
anywhere in the hierarchies multiple times.

With the list hierarchy like above, the program that bakes the layers 
only needs to start at the bottom of the list to bake the first layer, 
and step up the list to bake the next layer, until it reaches the top. 
The keywords like "lower-body" and "upper-body" only denote where (or 
how) the textures (in sub-lists from that keyword) are baked onto the 
avatar.


___
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: extendingavatarwearables

[Dzonatas Sol]

+1 A 'change type' feature isn't needed for this project.

Nyx's proposed category layout can override the type as old types are 
just hints. Possible with an ability to just drag-n-drop a wearable 
between categories.

The proposed outfit list would allow more for arbitrary lists that 
wouldn't depend on type hints or any new ordinals for layer priority, 
yet a complete UI for such feature is not expected this cycle in the 
main viewer as noted. The solution is here, however, with further 
development. Instead of any need to convert a type into a new type, the 
category list can be converted to an outfit list that make sense. One 
can just wear the outfit list instead of wear the specific type.

For example, the outfit list could be a notecard with a specific 
description to denote it as a wearable, which the viewer reads to fill 
in the category list when worn. Maybe you want superman underwear worn 
underneath blue pants, so your create a werable notecard called 'Kent'. 
You also can create a notecard called 'Superman' that then lists the 
superman underwear over the blue pants. To change layer order is now 
simply an action to either wear 'Kent' outfit or wear 'Superman' outfit, 
even though both lists contain specific wearables. With such outfit 
lists, there is never a need to 'change type' on a specific wearable.

Carlo Wood wrote:
> If the goal is to be able to change the type, then
> I don't feel it should be part of this particular
> project.
>   

___
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

[Dzonatas Sol]

Iceweasel crashes when attempts are made to post any message in the 
forums. It happens as soon as the javascript editor loads.

Nyx Linden wrote:
> Forums for discussing multi-wearables and related issues can be found 
> here: 
> https://blogs.secondlife.com/community/forums/open-source/open-development/multi-wearables
>
> Please re-direct all multi-wearables related conversations there - I'd 
> like to keep all discussion centralized so everyone knows where to look 
> for the latest info!
>
>  -Nyx
>
> 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 directly 
>> with the community!
>>
>> -Nyx
>> 
>
> ___
> 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

[Dzonatas Sol]

Since the updated TPV, there doesn't seem any indication that LL wants 
to restrict or take away rights granted by the GPL. In fact, it 
compliments the GPL to further narrow the difference in liabilities 
between content and software.

LL doesn't seem to want to be liable for an obvious non-GPL written 
program that connects to the SL grid. A non-GPL program is obviously a TPV.

Why should anybody want a TPV that uploads broken content to SL grid? 
So, to not connect to SL grid and only connect to other worlds is the 
answer some concluded on how to not upload broken content to SL grid.

L. Christopher Bird wrote:
> On Wed, Mar 31, 2010 at 10:06 AM, Gareth Nelson 
> mailto:gar...@garethnelson.com>> wrote:
>
>
> LL as copyright holder (or joint holder) can change the GPL with extra
> restrictions as much as they like - so long as they make it clear.
>
>
> Sure they can, but they must call this license something OTHER than 
> GPL. If they want to restrict freedoms granted by the GPL, then it 
> ceases to be GPL and becomes a new beast. Licensing under GPL which LL 
> has done in the past gives developers certain rights in the use of 
> that code.� Some freedoms and rights that the TPV curtails.
>
> LL is free to license their code however they want. What they can't do 
> is gut the parts of GPL they disagree with and still call it GPL.
>
> By licensing the viewer under GPL and the preamble to the TPV seems to 
> indicate this is their desire to continue to do so, implies a certain 
> promise to allow certain things to be done with the software.� If LL 
> wants to restrict or take away rights granted by the GPL THEY MUST NOT 
> CALL THEIR LICENSE GPL OR USE THE GPL PREAMBLE IN THEIR LICENSE.
>
> http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL
>
> �-- ZenMondo
>
> 
>
> ___
> 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

[Dzonatas Sol]

Do you mean that any GPL code is TPV? It doesn't seem logical to say "a 
TPV is GPL code," as that doesn't fit all cases.

The TPV even states: "This Policy 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, and for participating in our Viewer Directory."

In that statement, the source code under GPL, without modification, from 
LL is not a third-party viewer. Such state of source code is a base 
reference in which compliance to the network protocol helps prevent 
content breakage, as from the TPV: "The Third-Party Viewer must use a 
protocol that is compatible with the protocol of Linden Lab’s viewers as 
it is documented in our source code." That is under the section 
"Required Functionality and Disclosures"

There are two absolutes, source code that has the required functionality 
and source code that doesn't have required functionality.

There is what people seem to misunderstand: "If your Third-Party Viewer 
departs from our protocol, you must clearly document your departures 
either in the source code that you publish for the Third-Party Viewer or 
in another publicly available location." If people don't want to look at 
the GPL'd source code released from LL, then there is no way for them to 
clearly document their departure from such source code other than to say 
they reversed engineered it.

How is it a bad thing is LL asks a developer to alter there TPV because 
it breaks content. LL might have got a complaint about some product that 
doesn't work on their grid because it was uploaded under a TPV and sold 
to a person with an official viewer. This is where the TPV and GPL 
compliment each other to help resolve such mess.

Ron Festa wrote:
> Actually a TPV is GPL code. The core of the viewer and all additions 
> to the code are subject to the GPLv2. Your comment in that regards 
> doesn't make much sense. The TPV Policy is about what can and can't 
> connect the the grids owned and operated by Linden Lab, more so then 
> in-world content as we can all agree that the sections on Prohibited 
> Features and IP Rights are No Brainer clauses all of us for the most 
> part respect. Also I don't understand what you mean by uploading 
> broken content.
>
> The problem those of us who contribute to TPV's (I contributed to 
> Meerkat and now Imprudence if you wanted to dispute whether or not I 
> actually contribute anything) is basically what was summarized by the 
> Imprudence Viewer team: http://bit.ly/d2KxvI . If we agree with the 
> TPVP we pretty much have to alter our TPV at the Lindens' whims for 
> whatever reason they can find. Also if some black hat alters for 
> example Imprudence's or Emerald's Import/Export feature to ignore 
> ownership the developer team can be held legally responsible because 
> even though the Import/Export feature was altered, it was still their 
> code at the core and by the TPVP agreed to take on that liability. 
>
> Ron Festa
> Virtual Worlds Admin
> Division of Continuing Studies at Rutgers University
> PGP key: http://bit.ly/b1ZyhY
> Phone: 732-474-8583
>
>
> On Wed, Mar 31, 2010 at 1:28 PM, Dzonatas Sol  <mailto:dzona...@gmail.com>> wrote:
>
> Since the updated TPV, there doesn't seem any indication that LL wants
> to restrict or take away rights granted by the GPL. In fact, it
> compliments the GPL to further narrow the difference in liabilities
> between content and software.
>
> LL doesn't seem to want to be liable for an obvious non-GPL written
> program that connects to the SL grid. A non-GPL program is
> obviously a TPV.
>
> Why should anybody want a TPV that uploads broken content to SL grid?
> So, to not connect to SL grid and only connect to other worlds is the
> answer some concluded on how to not upload broken content to SL grid.
>
> L. Christopher Bird wrote:
> > On Wed, Mar 31, 2010 at 10:06 AM, Gareth Nelson
> > mailto:gar...@garethnelson.com>
> <mailto:gar...@garethnelson.com <mailto:gar...@garethnelson.com>>>
> wrote:
> >
> >
> > LL as copyright holder (or joint holder) can change the GPL
> with extra
> > restrictions as much as they like - so long as they make it
> clear.
> >
> >
> > Sure they can, but they must call this license something OTHER than
> > GPL. If they want to restrict freedoms granted by the GPL, then it
> > ceases to be GPL and becom

[opensource-dev] SNOW-375 Binary Package Available

[Dzonatas Sol]

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 


Source: http://gitweb.dzonux.net/?p=snowglobe-1.4-375.git 


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

Re: [opensource-dev] So you don't like the new TOS and wanna move to the OS grid?

[Dzonatas Sol]

Client-side physics is a must have in the new features. The first 
implementation probably would be for avatar clothes, even if the physics 
stay pretty static or just not-so-fluid. Anything is better then some 
attachment that tends to eviscerate the avatar.

Don't mention client-side physics or any kind of physics prediction on 
opensim maillist. You get "colorful" remarks by the admins there. They 
seem not want any kind of physic prediction or client-side physics. It 
seems like opensim is not an option for such avatar features.

I don't mean just linear physics prediction either. I mean even the 
simple type where if objects are static (easily predictable by a 
toggle), then download the static object in bulk as a set before one 
actually arrives at a sim or is logged-in. That way there is no delay 
upon login itself or when 30+ avatars decide to join a sim all at once 
(like at world2worlds evets where the scene doesn't change).

I mentioned Burning Man event earlier on this list on how people could 
subscribe to content a week before they actually visit the sim. Anyways...

Dale Mahalko wrote:
> Simple physics only with the ground. All objects are phantom. I'd
> think the OSGrid default login would want to showcase the
> collision-resolving capabilities of the more advanced open physics
> engines, but oh well.
>   

___
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

[Dzonatas Sol]

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 =)
>
>
> ___
> 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

[Dzonatas Sol]

That's correct.

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

___
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

[Dzonatas Sol]

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  <mailto: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...@gmail.com <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/bi

Re: [opensource-dev] SNOW-375 Binary Package Available

[Dzonatas Sol]

Philippe (Merov) Bossut wrote:
>
> - 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.


When SNOW-375 reaches more of a 1.0 version of the patch (and probably 
updated for SG2.0), then we'll work on the C.A. Until then, I would like 
to see the patch standardized more before others start to rely on such 
REST resources -- less hassle. I've collected wide-range various input, 
so far.
___
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 sync with Viewer 2.0

[Dzonatas Sol]

I just checked out revision 3313 from 
https://svn.secondlife.com/svn/linden/projects/2010/snowglobe/trunk

After plain  ./develop.py with no options , i got an error

$ make
[  0%] Built target cmake
[  0%] Built target llaudio
[  3%] Built target stage_third_party_libs
[  3%] Built target llcommon_tests
[  3%] Building CXX object llcommon/CMakeFiles/llcommon.dir/llcoros.o
In file included from 
/home/dzonatas/workspace/snowglobe.2.0/indra/../libraries/include/boost/coroutine/coroutine.hpp:44,
 from 
/home/dzonatas/workspace/snowglobe.2.0/indra/llcommon/llcoros.h:39,
 from 
/home/dzonatas/workspace/snowglobe.2.0/indra/llcommon/llcoros.cpp:39:
/home/dzonatas/workspace/snowglobe.2.0/indra/../libraries/include/boost/coroutine/detail/coroutine_impl.hpp:59:
 
error: declaration of 'typedef class 
boost::coroutines::detail::context_base 
boost::coroutines::detail::coroutine_impl::context_base'
/home/dzonatas/workspace/snowglobe.2.0/indra/../libraries/include/boost/coroutine/detail/context_base.hpp:55:
 
error: changes meaning of 'context_base' from 'class 
boost::coroutines::detail::context_base'
make[2]: *** [llcommon/CMakeFiles/llcommon.dir/llcoros.o] Error 1
make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
make: *** [all] Error 2


Haven't fully tracked this one down, so didn't file a jira.


Philippe (Merov) Bossut wrote:
> Hi all,
>
> Yes, there were a bunch of missed added files and other issues that 
> actually made the repository not complete, and therefore, not 
> buildable. I did a serie of commits today to fix that. I've been able 
> to build on Mac and Windows at least.
>
> Now, I'm still working on fixing the opensrc-build.sh script which is 
> used to produced the binaries. I hope to get build to pass on 
> Parabuild for Mac and Windows shortly.
>
> Thanks for your patience.
>
> 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] Snowglobe 2.0 sync with Viewer 2.0

[Dzonatas Sol]

Just to note: there is a related jira here about such patch: 
http://jira.secondlife.com/browse/SNOW-505

SNOW-505 is about standalone build instead of the ll downloaded libs.

Same error, however.

Lynx Linden wrote:
> This is a problem with the packaged boost headers - they don't seem to
> compile on Linux under gcc 4.x. I've attached a patch for the
> libraries/include/boost/coroutine/detail/{coroutine_impl.hpp,posix_utility.hpp}
> files that should get you going in the short term.
>
> Ultimately though we should build a new version of the boost package
> with that patch applied to it. Filing a JIRA to track this would be
> great.
>
> Cheers,
>
> Lynx.
>
>
>
> On Thu, Apr 8, 2010 at 2:22 AM, Dzonatas Sol  wrote:
>   
>> I just checked out revision 3313 from
>> https://svn.secondlife.com/svn/linden/projects/2010/snowglobe/trunk
>>
>> After plain �./develop.py with no options , i got an error
>>
>> $ make
>> [ �0%] Built target cmake
>> [ �0%] Built target llaudio
>> [ �3%] Built target stage_third_party_libs
>> [ �3%] Built target llcommon_tests
>> [ �3%] Building CXX object llcommon/CMakeFiles/llcommon.dir/llcoros.o
>> In file included from
>> /home/dzonatas/workspace/snowglobe.2.0/indra/../libraries/include/boost/coroutine/coroutine.hpp:44,
>> � � � � � � � � from
>> /home/dzonatas/workspace/snowglobe.2.0/indra/llcommon/llcoros.h:39,
>> � � � � � � � � from
>> /home/dzonatas/workspace/snowglobe.2.0/indra/llcommon/llcoros.cpp:39:
>> /home/dzonatas/workspace/snowglobe.2.0/indra/../libraries/include/boost/coroutine/detail/coroutine_impl.hpp:59:
>> error: declaration of 'typedef class
>> boost::coroutines::detail::context_base
>> boost::coroutines::detail::coroutine_impl> ContextImpl>::context_base'
>> /home/dzonatas/workspace/snowglobe.2.0/indra/../libraries/include/boost/coroutine/detail/context_base.hpp:55:
>> error: changes meaning of 'context_base' from 'class
>> boost::coroutines::detail::context_base'
>> make[2]: *** [llcommon/CMakeFiles/llcommon.dir/llcoros.o] Error 1
>> make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
>> make: *** [all] Error 2
>>
>>
>> Haven't fully tracked this one down, so didn't file a jira.
>>
>>
>> Philippe (Merov) Bossut wrote:
>> 
>>> Hi all,
>>>
>>> Yes, there were a bunch of missed added files and other issues that
>>> actually made the repository not complete, and therefore, not
>>> buildable. I did a serie of commits today to fix that. I've been able
>>> to build on Mac and Windows at least.
>>>
>>> Now, I'm still working on fixing the opensrc-build.sh script which is
>>> used to produced the binaries. I hope to get build to pass on
>>> Parabuild for Mac and Windows shortly.
>>>
>>> Thanks for your patience.
>>>
>>> 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
>>
>> 

___
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 sync with Viewer 2.0

[Dzonatas Sol]

I got it to compile to the secondlife-bin link stage, but then I got a 
link error:

/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/libSM.so: undefined 
reference to `uuid_gener...@uuid_1.0'
/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/libSM.so: undefined 
reference to `uuid_unparse_lo...@uuid_1.0'
collect2: ld returned 1 exit status

It does try to link against libuuid, with this link order:

 -lndofdev -lXinerama -lboost_program_options-gcc41-mt 
-lboost_regex-gcc41-mt -lgobject-2.0 -lglib-2.0 -lGLU -lGL -lSM -lICE 
-lX11 -lXext -lGLU -lGL -lSM -lICE -lX11 -lXext -lSDL -latk-1.0 
-lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lXinerama -lglib-2.0 -lgmodule-2.0 
-lgobject-2.0 -lgthread-2.0 -lgtk-x11-2.0 -lpango-1.0 -lpangoft2-1.0 
-lpangox-1.0 -lpangoxft-1.0 -lxmlrpc-epi -lELFIO 
../viewer_components/login/liblllogin.a ../llmessage/libllmessage.a 
-lcurl -lcares -lssl -lcrypto -lxmlrpc-epi ../llrender/libllrender.a 
../llimage/libllimage.a ../llimagej2coj/libllimagej2coj.a -lopenjpeg 
-ljpeg -lpng12 -lfreetype -lGLU -lGL -lSM -lICE -lX11 -lXext -lSDL 
../llxml/libllxml.a ../llvfs/libllvfs.a ../llmath/libllmath.a 
../llcommon/libllcommon.so -laprutil-1 -ldb-4.2 -luuid -ldb-4.2 -luuid 
-lrt -lapr-1 -lboost_program_options-gcc41-mt -lboost_regex-gcc41-mt -lz 
-lexpat


This might be a recent change in compiler which forces one to use GCC 
4.1...  and I didn't see this one in jira.

I'll work this issue out more to see if it is merely a GCC4.4/GCC4.1 
difference.


___
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 sync with Viewer 2.0

[Dzonatas Sol]

Here is my notes on how to compile with schroot, so you can make an 
environment specifically for this compilation:

https://wiki.secondlife.com/wiki/User:Dzonatas_Sol/Snowglobe


Robert Martin wrote:
> As a sidebar to this is the documents on how to compile the viewer
> actually current??
> If somebody would be willing to walk me through this i could help find
> out what is correct
> (note i have Mandriva 2010)
>
>
>   

___
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 sync with Viewer 2.0

[Dzonatas Sol]

I just tried it again, so now I can confirm there is no difference 
between a compilation with G++-4.1 or G++-4.4 in relation to this error.

Linking CXX executable secondlife-bin
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libSM.so: undefined 
reference to `uuid_gener...@uuid_1.0'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libSM.so: undefined 
reference to `uuid_unparse_lo...@uuid_1.0'
collect2: ld returned 1 exit status

Maybe something special about libSM that it needs a specific version of 
libuuid, or maybe as Lance suggested, it doesn't use the the LL supplied 
versus the system version.

Lance Corrimal wrote:
> I'm having the same problem on opensuse 11.2.
> until recently it built fine... after some change introduced a script 
> which replaces the prebuilt libs with the systemwide installed ones, 
> it stopped building with exactly that error.
>
> why do i even have to have the build script download the prebuilt libs 
> when they dont get used?
>
>
> bye,
> LC
>
>
> Am Donnerstag 08 April 2010 schrieb Dzonatas Sol:
>   
>> I got it to compile to the secondlife-bin link stage, but then I
>> got a link error:
>>
>> /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/libSM.so:
>> undefined reference to `uuid_gener...@uuid_1.0'
>> /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/libSM.so:
>> undefined reference to `uuid_unparse_lo...@uuid_1.0'
>> collect2: ld returned 1 exit status
>>
>> It does try to link against libuuid, with this link order:
>>
>>  -lndofdev -lXinerama -lboost_program_options-gcc41-mt
>> -lboost_regex-gcc41-mt -lgobject-2.0 -lglib-2.0 -lGLU -lGL -lSM
>> -lICE -lX11 -lXext -lGLU -lGL -lSM -lICE -lX11 -lXext -lSDL
>> -latk-1.0 -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lXinerama -lglib-2.0
>> -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lgtk-x11-2.0
>> -lpango-1.0 -lpangoft2-1.0 -lpangox-1.0 -lpangoxft-1.0
>> -lxmlrpc-epi -lELFIO
>> ../viewer_components/login/liblllogin.a ../llmessage/libllmessage.a
>> -lcurl -lcares -lssl -lcrypto -lxmlrpc-epi
>> ../llrender/libllrender.a ../llimage/libllimage.a
>> ../llimagej2coj/libllimagej2coj.a -lopenjpeg -ljpeg -lpng12
>> -lfreetype -lGLU -lGL -lSM -lICE -lX11 -lXext -lSDL
>> ../llxml/libllxml.a ../llvfs/libllvfs.a ../llmath/libllmath.a
>> ../llcommon/libllcommon.so -laprutil-1 -ldb-4.2 -luuid -ldb-4.2
>> -luuid -lrt -lapr-1 -lboost_program_options-gcc41-mt
>> -lboost_regex-gcc41-mt -lz -lexpat
>>
>>
>> This might be a recent change in compiler which forces one to use
>> GCC 4.1...  and I didn't see this one in jira.
>>
>> I'll work this issue out more to see if it is merely a
>> GCC4.4/GCC4.1 difference.
>>
>>
>> ___
>> 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] Soft body physics

[Dzonatas Sol]

Here is some videos to watch...

http://www.youtube.com/watch?v=MoQh4R1-Vjs
http://www.youtube.com/watch?v=oOK1L0Uo8KM
http://www.youtube.com/watch?v=xfrM973spw0
http://www.youtube.com/watch?v=8z2zDwzK5Kg
http://www.youtube.com/watch?v=1C6LrDzjfRw

...so the ability is there.




Dale Mahalko wrote:
> Can you point to anything in 3D animation that already does this sort
> of thing? I don't think it exists.
>
> The idea sounds reminiscent of an idea I posted on this list a few
> years ago, wrapping a sculptie mesh around a collection of prims and
> "deflating" the mesh until its vertices form-fit the prims within,
> sort of like vacuum-forming with plastic, to quickly make a multiprim
> object into a single sculptie.
>
> ,
>
> Sending raw soft-mesh vertex points to the client to accurately show
> the soft mesh shape would likely be far too slow. A simple mesh can
> contain a few hundred points, each with X/Y/Z coordinates, and these
> must all be adjusted for each new "frame" of the 3D renderer.
>
> You would probably have to simplify and generalize the soft body
> modeling to make it fast enough for a slow network connection, and
> leave the actual modeling up to the local computer. Define general
> static forces that pin the mesh around its edge and on its surface,
> such as the flattening buttons like on chair cushions. To "inflate"
> the mesh into a bun or balloon, assign a general direction of billow.
> And if desired, also adjust the elasticity of the rays linking
> vertices together to tighten up or loosen the overall shape, such as
> along seams on pillows..
>
> To deform the mesh the server only sends a force and a 3D impression
> shape to the client, such as a sphere X meters in diameter pressing
> into the mesh surface with Y newtons of force. The client then uses
> that simple data in combination with the defined static forces to
> dynamically deform the soft mesh vertices, such as representing your
> avatar's feet pushing down on surface of a trampoline.
>
> Just don't ask me to program that. :-)
>
> - Dale Mahalko / Scalar Tardis
>
>
> On Wed, Apr 7, 2010 at 7:25 PM, Glen Canaday  wrote:
>   
>> I can imagine fields of waving grass, rubber couches and trampolines
>> 
> ___
> 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 sync with Viewer 2.0

[Dzonatas Sol]

Successfully compiled, yet webkit doesn't want to load (yet it loaded 
fine on the official V2.0 download)

Copied over older LL supplied libuuid.so.1 with newer libuuid.so.1.3.0 
was all that was needed, so LL just needs to upgrade their prebuilt uuid 
lib to 1.3+.

http://jira.secondlife.com/browse/SNOW-606



Johnnie Carling wrote:
> On 04/08/10 5:40:53 pm, Dzonatas Sol wrote:
>   
>> Maybe something special about libSM that it needs a specific version of 
>> libuuid, or maybe as Lance suggested, it doesn't use the the LL supplied 
>> versus the system version.
>> 
>
> FYI. I ran into this last fall. Using the system libuuid (libuuid.so.1.3.0 in 
> debian sid) worked for me.
>
> --
> Johnnie Carling
> ___
> 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] Brown-bag meeting to continue dialog on TVPV next Tuesday (4/13)

[Dzonatas Sol]

Hi Joe,

In case I don't make the Brown Bag, I just wanted to point out the fact 
that simply developers, which includes how Linden Lab has invested 
resources to sustain such world, don't share a view with users that 
Virtual Reality that Virtual Reality is not just a game. This 
realization is actually desired despite the politics of how we all move 
from what has been said virtual is not really virtual. I won't digress 
here about the subject, yet the monitor in front of us we can't touch 
and see and that is not 'fake' as some people treat virtual to only 
mean. I even imagine a house size 'monitor' where every wall can act as 
an interactive colorful display that consists of many organized liquid 
crystal units spread on like paint. That's the future... for now we have 
e-paper. It's something we can't really just say is not possible 
anymore, and it is something that may affect how we see content (or 
broken content) in relation to policies like the TPV.

I gather from the TPV that is it intended to help prevent broken 
content, yet it has been easily attacked. I think the notion of how to 
deal with broken content gets lost when developers worry more about how 
to protect their liabilities. Developers simply want to say 'use at your 
own risk' from a software development standpoint, yet that doesn't give 
anything to help ensure content doesn't break.

With that in mind, any word that implies 'responsibility' somehow hasn't 
carried the concern about how to prevent content breakage when anybody 
connects to SL Grid.I'm sure we don't want to paint our houses with a 
'use at your own risk' and expect to say it is baby-safe. What would a 
baby see if an accidental bump in the wall activated something that 
parents would consider an undesirable experience for baby or child. I 
can only imagine the horror if the scene of the wall suddenly changed to 
spook the baby as if monsters came out of the wall. Maybe this isn't 
quite broken content, yet it is still an ideal situation to mention to 
level where 'responsibility' is distinct from 'liabilities'.

Just something to think about


Joe Miller wrote:
> Morgaine,
>
> Thanks for asking.  My interest is to listen to specific concerns 
> voiced by the majority of the community *and* (more importantly) take 
> */proposed solutions/* to those concerns under advisement before the 
> policy becomes effective on April 30.  It won't be very productive for 
> anyone if it's just a grousing session about legal theory or 
> hypothetical situations that may or may not occur in the future.  Yes, 
> I will take all serious proposals back into the company for serious 
> consideration.  But, make no mistake, I'm not asking for a change set 
> that makes one person happier at a time.  I'm looking for the minimum 
> change set that represents the broadest possible consensus among the 
> community of TPV authors.
>
> So, yours are good questions, and I do intend to champion the TPV 
> community's collective voice in this process.  I hope we emerge with 
> something actionable out of these meetings.
>
> -- Joe
>

___
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] Brown-bag meeting to continue dialog on TVPV next Tuesday (4/13)

[Dzonatas Sol]

I'm not sure what you mean it didn't quite work.

Anyways, I appreciate that Joe wants to gather this Brown-Bag, so we can 
talk specifics in words.

Tigro Spottystripes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> a baby can still crawl over the TV remote and turn it on right when a
> horror movie is playing, that baby analogy didn't quite work
>
> On 10/4/2010 14:14, Dzonatas Sol wrote:
>   
>> Hi Joe,
>>
>> In case I don't make the Brown Bag, I just wanted to point out the fact 
>> that simply developers, which includes how Linden Lab has invested 
>> resources to sustain such world, don't share a view with users that 
>> Virtual Reality that Virtual Reality is not just a game. This 
>> realization is actually desired despite the politics of how we all move 
>> from what has been said virtual is not really virtual. I won't digress 
>> here about the subject, yet the monitor in front of us we can't touch 
>> and see and that is not 'fake' as some people treat virtual to only 
>> mean. I even imagine a house size 'monitor' where every wall can act as 
>> an interactive colorful display that consists of many organized liquid 
>> crystal units spread on like paint. That's the future... for now we have 
>> e-paper. It's something we can't really just say is not possible 
>> anymore, and it is something that may affect how we see content (or 
>> broken content) in relation to policies like the TPV.
>>
>> I gather from the TPV that is it intended to help prevent broken 
>> content, yet it has been easily attacked. I think the notion of how to 
>> deal with broken content gets lost when developers worry more about how 
>> to protect their liabilities. Developers simply want to say 'use at your 
>> own risk' from a software development standpoint, yet that doesn't give 
>> anything to help ensure content doesn't break.
>>
>> With that in mind, any word that implies 'responsibility' somehow hasn't 
>> carried the concern about how to prevent content breakage when anybody 
>> connects to SL Grid.I'm sure we don't want to paint our houses with a 
>> 'use at your own risk' and expect to say it is baby-safe. What would a 
>> baby see if an accidental bump in the wall activated something that 
>> parents would consider an undesirable experience for baby or child. I 
>> can only imagine the horror if the scene of the wall suddenly changed to 
>> spook the baby as if monsters came out of the wall. Maybe this isn't 
>> quite broken content, yet it is still an ideal situation to mention to 
>> level where 'responsibility' is distinct from 'liabilities'.
>>
>> Just something to think about
>>
>>
>> Joe Miller wrote:
>> 
>>> Morgaine,
>>>
>>> Thanks for asking.  My interest is to listen to specific concerns 
>>> voiced by the majority of the community *and* (more importantly) take 
>>> */proposed solutions/* to those concerns under advisement before the 
>>> policy becomes effective on April 30.  It won't be very productive for 
>>> anyone if it's just a grousing session about legal theory or 
>>> hypothetical situations that may or may not occur in the future.  Yes, 
>>> I will take all serious proposals back into the company for serious 
>>> consideration.  But, make no mistake, I'm not asking for a change set 
>>> that makes one person happier at a time.  I'm looking for the minimum 
>>> change set that represents the broadest possible consensus among the 
>>> community of TPV authors.
>>>
>>> So, yours are good questions, and I do intend to champion the TPV 
>>> community's collective voice in this process.  I hope we emerge with 
>>> something actionable out of these meetings.
>>>
>>> -- Joe
>>>
>>>   
>> ___
>> 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/
>
> iEYEARECAAYFAkvAtJMACgkQ8ZFfSrFHsmV8rACfWziTD7lXwmEONUMwduAzzZ+X
> UwIAnjdlpsmXYRWd1Lur9gHpt5CQoEDC
> =ozxl
> -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] Two Worlds

[Dzonatas Sol]

a...@skyhighway.com wrote:
> For the Big Picture SL presentation i can see something like all the SL
> windows, including all the chat, inventory, group, etc - everything (even
> HUDs?), being just windows for the OS with the VW its own window that
> maybe is maximized and maybe isn't.  In maximized mode the VW window could
> have the ability to "draw in" or spawn inside without "leaving" the VW any
> or all of the windows for chat, inventory, etc in their floaty, sometimes
> transparent mode like the Terminator's heads up display that so many like
> so well!  Y'know, the best of all worlds?
>   

Do you mean something like an interface that allows us to do this:

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

___
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] Requesting Linden Response: Please move TPVP Topics to a different mailing list

[Dzonatas Sol]

+1

I  already trashed a few attempts to write an e-mail to try to say what 
you have.

Jonathan Irvin wrote:
> To Whom It May Concern:
>
> I'm requesting Linden Lab's response to this inquiry due to the recent 
> influx of new topic related...or should I say unrelated to the 
> development of the SnowGlobe viewer.  Lately, when I open my email, I 
> get 5-10 different topics and responses daily to the recent changes 
> for the Third Party Viewer policy and I feel that this is not related 
> to SnowGlobe or related development at all.
>
> To "clear the pipes", can we please move these discussions to a 
> different forum or list so valid OpenSource development questions are 
> not lost in the flames, complaints, and discussions related to this 
> specific topic?
>
> I do not feel it is valid in this forum to talk about which 
> Third-Party Viewers in the directory were already impersonated or 
> which part of the third party viewer policy they do not like.
>
> Linden Labs, if you can please isolate this to another forum, I bet 
> those who are truly interested in the opensource development of the 
> Second Life viewer would be more in tuned to staying here rather than 
> wake up to read yet another unproductive "I hate LL and the TPVP lets 
> get together and share our misery post".
>
> Respectfully & Best Regards,
>
> Jonathan Irvin
> SL Resident of 5 Years.
> 
>
> ___
> 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] Ironpython (was: Requesting Linden Response: Please move TPVP Topics to a different mailing list)

[Dzonatas Sol]

Compare this list to here: 
http://lists.ironpython.com/pipermail/users-ironpython.com
Although stated as a combined user/dev list and open to related DLR/CLR 
discussion...: http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

... the signal to noise, on that mail-list, remains much more on the 
signal side, and it commonly gets more unmoderated traffic than this 
opensource-dev list.


And yes, I brought up ironpython with a shameless plug that Ironpython 
2.6 is almost in Debian stable. If anyone has done AST & resource 
compiles with ironpython probably has hacked their compile to include 
the entire standard python lib into a single exe, which makes it very 
easily shippable product with no install complexity for platforms that 
support Mono/.NET.

It would be nice if something like CMake was written in a DLR instead of 
native, so then any updates to CMake wouldn't need to wait to move out 
of the experimental cycles of the platforms in order to compile to 
stable (like Debian Lenny, for example).

Also note the potential pluggability of IL/DLR...



Ron Festa wrote:
> I feel your frustration, however, this is the /*opensource-dev*/ 
> mailing list *not* the /*snowglobe-dev*/ mailing list. Both SnowGlobe 
> and TPV's are open source viewers based on Linden Lab's mainline 
> viewer the only difference is Snowglobe is distributed by LL. 
> Discussion on policies that effect open source development should be 
> encouraged. If you only want to see stuff relating to SnowGlobe then 
> either encourage LL create a snowglobe-dev list or configure your mail 
> filters to only allow email related to snowglobe to enter your inbox 
> from this list.
>
> Ron Festa
> Virtual Worlds Admin
> Division of Continuing Studies at Rutgers University
> PGP key: http://bit.ly/b1ZyhY
> Phone: 732-474-8583
>
>
> On Wed, Apr 14, 2010 at 8:52 AM, Jonathan Irvin  > wrote:
>
> To Whom It May Concern:
>
> I'm requesting Linden Lab's response to this inquiry due to the
> recent influx of new topic related...or should I say unrelated to
> the development of the SnowGlobe viewer.� Lately, when I open my
> email, I get 5-10 different topics and responses daily to the
> recent changes for the Third Party Viewer policy and I feel that
> this is not related to SnowGlobe or related development at all.
>
> To "clear the pipes", can we please move these discussions to a
> different forum or list so valid OpenSource development questions
> are not lost in the flames, complaints, and discussions related to
> this specific topic?
>
> I do not feel it is valid in this forum to talk about which
> Third-Party Viewers in the directory were already impersonated or
> which part of the third party viewer policy they do not like.
>
> Linden Labs, if you can please isolate this to another forum, I
> bet those who are truly interested in the opensource development
> of the Second Life viewer would be more in tuned to staying here
> rather than wake up to read yet another unproductive "I hate LL
> and the TPVP lets get together and share our misery post".
>
> Respectfully & Best Regards,
>
> Jonathan Irvin
> SL Resident of 5 Years.
>
> ___
> 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

[opensource-dev] client-side physics and general relativity

[Dzonatas Sol]

I want to share a use-case/concept for physic simulation where the 
client and sever wouldn't have to send object updates, or at least there 
wouldn't be as many updates needed to send from the sim to the client.

Given we can use general relativity more as a mutual agreement rather 
than assume it is the only way reality changes; we could further expend 
such mutual agreement between a server and client as they simulate 
physics. Now don't expect FTL changes for this, yet we can use the same 
analogy and define a limit. Let's use one that LL has already defined as 
max velocity an object moves through a sim.

Now, let's say we have two objects. Object (A) is within 10m to an 
avatar. Another object (B) is 50m away for that avatar. Now, since 
object (A) is within a distance an object can move within a second of 
max velocity, the client can be given rights to simulate object (A), and 
the simulator wouldn't send any updates to the client if the client does 
such. Since object (B) is outside the distance of an object can move 
within a second at max velocity, the simulator would continue to send 
updates to the client about object (b) only if in view (as it does now).

If object (A) and object (B) are static, as in they never move, then the 
client would fully control its position within that relative second of 
space and all physics. If the avatar bounces off the static object, the 
client doesn't need to send updates to the sim unless the object needs 
to know if it was touched.

If the objects aren't static or if there are more avatars, then there 
are several negotiation and scenarios that could happen, yet let's not 
digress immediately away from the basic use-case/concept stated above.

Bottomline, this should be negotiable. The sim may not allow it at all 
if if the sim needs full physics control. The avatar may want to only be 
in sims that don't take full control of physics. If the client simulates 
some objects then the sim is expect to simulate the same objects. The 
two simulations should be basically in sync, yet accuracy of being in 
sync should be negotiable also.

Relative second of space can be quickly calculated, for example, ( max 
diameter of avatar + 1 second distance of max velocity ) * 3.333...  
(basically like pi r squared)

=)


___
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 physics and general relativity

[Dzonatas Sol]

That's true for the case of non-static objects. We could, however, 
predict how fast an object changes and negotiate that limit, and that's 
basically what there is to agree upon for what is relative.

For example, let's  say an avatar moves around a sim of mostly static 
objects. It can do most of the work for client-side physics, so those 
updates are lowered traffic. When the avatar touches a non-static 
object, it could just send a signal to the sim that it touched the 
object. The sim then decides if it needs to send an update back to the 
client. If the object acts like a static object even if it is set 
non-static, then no update is needed from sim to client.

Another example, lets say the avatar has lots of animated attachments. 
The avatar also moves around a sim of mostly static object, but the 
attachments are obvious non-static since they animate. Since the 
attachments are all within the avatar's relative space, the client-side 
physics can handle all the motion of the attachments. The sim may not 
need to know anything about the attachments unless they bump into 
something non-static.

Soft body physics in mind...


Tateru Nino wrote:
> Hmm. However, with virtual objects the physical properties aren't fixed.
> Unlike regular matter, the physical properties of an SL object can
> change at any time. In fact - and I grant I only have anecdotal
> information to support this - I think it is less likely for an object's
> physical properties to remain constant than it is for them to change.
>
> On 16/04/2010 2:57 PM, Dzonatas Sol wrote:
>   
>> I want to share a use-case/concept for physic simulation where the 
>> client and sever wouldn't have to send object updates, or at least there 
>> wouldn't be as many updates needed to send from the sim to the client.
>>
>> Given we can use general relativity more as a mutual agreement rather 
>> than assume it is the only way reality changes; we could further expend 
>> such mutual agreement between a server and client as they simulate 
>> physics. Now don't expect FTL changes for this, yet we can use the same 
>> analogy and define a limit. Let's use one that LL has already defined as 
>> max velocity an object moves through a sim.
>>
>> Now, let's say we have two objects. Object (A) is within 10m to an 
>> avatar. Another object (B) is 50m away for that avatar. Now, since 
>> object (A) is within a distance an object can move within a second of 
>> max velocity, the client can be given rights to simulate object (A), and 
>> the simulator wouldn't send any updates to the client if the client does 
>> such. Since object (B) is outside the distance of an object can move 
>> within a second at max velocity, the simulator would continue to send 
>> updates to the client about object (b) only if in view (as it does now).
>>
>> If object (A) and object (B) are static, as in they never move, then the 
>> client would fully control its position within that relative second of 
>> space and all physics. If the avatar bounces off the static object, the 
>> client doesn't need to send updates to the sim unless the object needs 
>> to know if it was touched.
>>
>> If the objects aren't static or if there are more avatars, then there 
>> are several negotiation and scenarios that could happen, yet let's not 
>> digress immediately away from the basic use-case/concept stated above.
>>
>> Bottomline, this should be negotiable. The sim may not allow it at all 
>> if if the sim needs full physics control. The avatar may want to only be 
>> in sims that don't take full control of physics. If the client simulates 
>> some objects then the sim is expect to simulate the same objects. The 
>> two simulations should be basically in sync, yet accuracy of being in 
>> sync should be negotiable also.
>>
>> Relative second of space can be quickly calculated, for example, ( max 
>> diameter of avatar + 1 second distance of max velocity ) * 3.333...  
>> (basically like pi r squared)
>>
>> =)
>>
>>
>> ___
>> 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 physics and general relativity

[Dzonatas Sol]

I don't think you thought through all cases. Consider blind users, as 
they would only be concerned with objects within relative space, then 
even on a busy sim the sim would not have to send any updates to the client.

Even if not blind, lets say someone has their view limit set only to 
relative space, as would be the potential possibility for those that 
mainly leave their client open for chat. Normally the viewer is set to 
greater than 64m away view distance, yet if someone has the chat window 
maximized then that distance isn't really needed. It would be an option 
to have the viewer automatically drop viewable distance to 30m or less, 
which would be optimal for chat distance.

It's a use-case/concept that is low-hanging fruit for client-side physics.

Dale Glass wrote:
> It seems to me you're optimizing for rather narrow cases: sims of mostly
> static objects, and presumably nobody else around. But why optimize for
> something that is going to be very fast already? 
>
> The most benefit would be gained from improving the performance of busy
> sims, but it sounds like those ideas would rarely work in such a case.
>
>
>   

___
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 physics and general relativity

[Dzonatas Sol]

This thread isn't about a mere box as you suggest. There thread is about 
how to take physics beyond that and allow the client to do part of the 
simulation, given a single use-case.

Tigro Spottystripes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> currently attachments don't bump on anything, and animations do not
> affect what the avatar collides with, avatars got a static bounding box
> and that is it
>
> On 16/4/2010 10:45, Dzonatas Sol wrote:
>   
>> That's true for the case of non-static objects. We could, however, 
>> predict how fast an object changes and negotiate that limit, and that's 
>> basically what there is to agree upon for what is relative.
>>
>> For example, let's  say an avatar moves around a sim of mostly static 
>> objects. It can do most of the work for client-side physics, so those 
>> updates are lowered traffic. When the avatar touches a non-static 
>> object, it could just send a signal to the sim that it touched the 
>> object. The sim then decides if it needs to send an update back to the 
>> client. If the object acts like a static object even if it is set 
>> non-static, then no update is needed from sim to client.
>>
>> Another example, lets say the avatar has lots of animated attachments. 
>> The avatar also moves around a sim of mostly static object, but the 
>> attachments are obvious non-static since they animate. Since the 
>> attachments are all within the avatar's relative space, the client-side 
>> physics can handle all the motion of the attachments. The sim may not 
>> need to know anything about the attachments unless they bump into 
>> something non-static.
>>
>> Soft body physics in mind...
>>
>>
>> Tateru Nino wrote:
>> 
>>> Hmm. However, with virtual objects the physical properties aren't fixed.
>>> Unlike regular matter, the physical properties of an SL object can
>>> change at any time. In fact - and I grant I only have anecdotal
>>> information to support this - I think it is less likely for an object's
>>> physical properties to remain constant than it is for them to change.
>>>
>>> On 16/04/2010 2:57 PM, Dzonatas Sol wrote:
>>>   
>>>   
>>>> I want to share a use-case/concept for physic simulation where the 
>>>> client and sever wouldn't have to send object updates, or at least there 
>>>> wouldn't be as many updates needed to send from the sim to the client.
>>>>
>>>> Given we can use general relativity more as a mutual agreement rather 
>>>> than assume it is the only way reality changes; we could further expend 
>>>> such mutual agreement between a server and client as they simulate 
>>>> physics. Now don't expect FTL changes for this, yet we can use the same 
>>>> analogy and define a limit. Let's use one that LL has already defined as 
>>>> max velocity an object moves through a sim.
>>>>
>>>> Now, let's say we have two objects. Object (A) is within 10m to an 
>>>> avatar. Another object (B) is 50m away for that avatar. Now, since 
>>>> object (A) is within a distance an object can move within a second of 
>>>> max velocity, the client can be given rights to simulate object (A), and 
>>>> the simulator wouldn't send any updates to the client if the client does 
>>>> such. Since object (B) is outside the distance of an object can move 
>>>> within a second at max velocity, the simulator would continue to send 
>>>> updates to the client about object (b) only if in view (as it does now).
>>>>
>>>> If object (A) and object (B) are static, as in they never move, then the 
>>>> client would fully control its position within that relative second of 
>>>> space and all physics. If the avatar bounces off the static object, the 
>>>> client doesn't need to send updates to the sim unless the object needs 
>>>> to know if it was touched.
>>>>
>>>> If the objects aren't static or if there are more avatars, then there 
>>>> are several negotiation and scenarios that could happen, yet let's not 
>>>> digress immediately away from the basic use-case/concept stated above.
>>>>
>>>> Bottomline, this should be negotiable. The sim may not allow it at all 
>>>> if if the sim needs full physics control. The avatar may want to only be 
>>&g

Re: [opensource-dev] client-side physics and general relativity

[Dzonatas Sol]

Do you understand the use-case I noted? As stated earlier: "If the 
objects aren't static or if there are more avatars, then there are 
several negotiation and scenarios that could happen, yet let's not 
digress immediately away from the basic use-case/concept stated above."


Tigro Spottystripes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> visually impaired people would still need to know if the door is open,
> if the trolley is on the station, if someone bumped into them etc
>
> On 16/4/2010 12:48, Dzonatas Sol wrote:
>   
>> I don't think you thought through all cases. Consider blind users, as 
>> they would only be concerned with objects within relative space, then 
>> even on a busy sim the sim would not have to send any updates to the client.
>>
>> Even if not blind, lets say someone has their view limit set only to 
>> relative space, as would be the potential possibility for those that 
>> mainly leave their client open for chat. Normally the viewer is set to 
>> greater than 64m away view distance, yet if someone has the chat window 
>> maximized then that distance isn't really needed. It would be an option 
>> to have the viewer automatically drop viewable distance to 30m or less, 
>> which would be optimal for chat distance.
>>
>> It's a use-case/concept that is low-hanging fruit for client-side physics.
>>
>> Dale Glass wrote:
>> 
>>> It seems to me you're optimizing for rather narrow cases: sims of mostly
>>> static objects, and presumably nobody else around. But why optimize for
>>> something that is going to be very fast already? 
>>>
>>> The most benefit would be gained from improving the performance of busy
>>> sims, but it sounds like those ideas would rarely work in such a case.
>>>
>>>
>>>   
>>>   
>> ___
>> 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/
>
> iEYEARECAAYFAkvIzXgACgkQ8ZFfSrFHsmX2nQCdHlBNhgn/8HtaivsklbcaMeRK
> oWUAnAmJsLFRcl9l9dlzAD+hKJvHfNV0
> =Avci
> -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

[opensource-dev] Interested in Terrain Advancement

[Dzonatas Sol]

There does seem to be a collective feel that the terrain needs to 
upgraded somehow. Even a Linden suggested maybe a way to override it if 
the builder choses, like with sim sized mega prims.

My first concern is LOD. The constant changes of LOD on the terrain make 
the appearance the terrain unnatural and unstable. There are times where 
we spend lots of time to get the terrain to look just perfectly aligned 
with other objects nearby. When one decides to walk away 20m, 40m, 60m, 
however, the perfect alignment becomes a prefect fashion statement for a 
drunk bulldozer. The hard work undertaken to detail the alignment of the 
terrain seems like a complete loss.

As I've used other renders, lets pick on Call of Duty, the terrain is 
pretty stable even at a distance. It has to be. The mere jump of LOD in 
the terrain could mean a way to cheat in Deathmatch sniper rounds. You 
know how snipers love to crawl around the terrain. That kind of 
stableness doesn't happen when the drunk bulldozer decides to 
rearrangement the landscape every frame you move. Call of Duty uses the 
Source Engine, yet this isn't a 'lets all switch over to the Source 
Engine' rant. It is a use-case that shows that even on old steampunk 
video cards there still have the coal to burn up the pixels and display 
a stable landscape. The use-case means, bottomline, it is possible.

Maybe a baby-step solution is just to have an option to turn-off the LOD 
for the current sim, and maybe nearby sims. The problem here, maybe, is 
that the changes to add vertex limits would be affected by this. It 
might not be all that simple like it was in the past without the vertex 
limits. Therefore, there would need to be separate vertex limits: one 
for the terrain and the rest for objects.

Here is another use-case with a collada file: Lets say I have a collada 
file that contains a very detailed structure of a volcano (terrain 
only).  The volcano is 1km wide. That crosses several 256m sims. There 
are lava tunnels that lead inside.

The suggested solution was to use a sim sized mega-prim. To do that with 
scuplties would be hard for more than just looks. Sculpties need to 
calculate all the phsyics, yet the collada file could have that already 
detailed and compiled with the file.

How do we do this with the stock viewer even if we used sculpties? The 
stock viewer doesn't include a "sit on this object here like one sits on 
land now anywhere" option. If we used a mega-prim, it would disabled the 
ability to sit anywhere on the terrain.

The other idea is to import a terrain, which is an available feature. 
That doesn't allow us to have multiple height maps, like lava tubes. If 
a lava tube crossed a sim to another, there would be a hole in the 
terrain in one sim. There current terrain engine doesn't allow holes. 
Multiple height maps would allow us to have holes in the terrain. The 
physics detail of a scupltie bent to make that hole doesn't preform (and 
I don't mean just frame optimization.. I mean like how a skirt clearly 
either looks good or not when you sit down kind of 'preform'.)

So, maybe the solution include that baby step.. to allow multiple height 
map layers. A Lava tube could be done with three layers. One for the 
bottom of the tunnel. One for the top. And one for the side of the 
volcano above the tunnel. There would be needed an extra feature with 
the height map to allow empty spaces, to allow where the tunnel opens 
into the side of the volcano.

So, before we even digress into the advantages of collada refineries, it 
seems the first two baby steps would be to fix LOD and allow an 
arbitrary number of terrain layers.

I would like to see what others think about this.

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

Re: [opensource-dev] Migrating open development focus to 2.x

[Dzonatas Sol]

Hi Oz,

There has been discussion in AWG and other various chat moments of what 
could be done. The primary suggestions seems to be able to hide the UI, 
but that doesn't mean it needs to be disabled. There is a debug option, 
CTRL-ALT-F1, that basically hides the UI, yet the mouse regions are 
still sensitive. If the mouse regions weren't sensitive, it would 
provide a means to hide the UI and allow other options.

For an example with the built-in UI hidden and an external UI present, 
please see this project: 
http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/Icesphere

Since the UI seems to be really the only issue, the above provides a 
solution to continue movement to 2.x.

Enjoy


Oz Linden (Scott Lawrence) wrote:
> I opened this in the 27 May IW open source meeting, and would like to 
> invite wider and more specific feedback.
>
> It's fairly clear that Linden Lab doesn't have the resources to devote 
> to active work on both Snowglobe 1.x and 2.x, and it's not efficient for 
> the community as a whole to be splitting effort.
>
> I'd like to fairly quickly get to the point where all our new work is 
> happening on the 2.x branch.  That said, I understand that might leave 
> behind things that the Snowglobe user/dev base wants and that some 
> people are not happy with some elements of 2.x.  What I'd like to know 
> is... what needs to happen to make that choice that most people can be 
> happy with?
>
> One of my goals is to increase the rate and volume at which Linden Lab 
> can (and _does_) take changes from the open source base into the 
> internal code, but unless we can keep everyone on the same branch, that 
> will be much more difficult.
>
> Please respond to this thread with your favorite reasons not to move 
> development to 2.x.   We will review the list at the 6 June open source 
> meeting with the goal of setting some priorities.
>
>
>
> To be clear... I don't object to anyone else working on 1.x at all; I'd 
> just like to know why so that we can tempt them to join us on 2.x
>
> ___
> 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] icesphere

[Dzonatas Sol]

Robert Martin wrote:
> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/Icesphere
> seems to be what website is availible
>
> hint for the developer
> 1 could you please get a website for this and not have your stuff
> scattered across 5 different sites
>   

Thank you for the requests. I'll try to get that done.


> 2 a patched build would be a good thing
>   


The patch itself is posted here: https://jira.secondlife.com/browse/SNOW-375

The SG2.0 patched source is here: 
http://gitweb.dzonux.net/?p=snowglobe-2.0-375.git

I planned to release the patched binary when version 0.10.2 of the patch 
is released. I been away for a month, so this was delayed.


Icesphere itself is here: 
http://mono.dzonux.net/file/Snowglobe375/icesphere.zip

After you start SG2.0 and login, then start Icesphere. It's a two-step 
process, but I started to add features to automate that into one. The 
sysicon/statusicon contains the menu to hide/show the UI windows.
___
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] Linux 64 bit libs / 64 bit non-standalone building

[Dzonatas Sol]

Oz Linden (Scott Lawrence) wrote:
> I'm particularly motivated to do that, in fact, since the Linux box that 
> Linden provided me with only runs the 64 bit version of Ubuntu...
>   

If you want to run the 32bit compile from 64bit machine, this page may help:
http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/Snowglobe

It sets up a 32bit chroot to run the compile.

Instead of 64bit libs, a *.deb file to resolve dependencies would be 
nice. This probably would solve some other issues where a distro has its 
own flavor of libs built. (i.e. pulse vs alsa)
___
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] icesphere

[Dzonatas Sol]

Hi,

Here is the new site:

http://icyspherical.blogspot.com

And, you can follow me on twitter:

http://twitter.com/Dzonatas_Sol

Slowly have gotten this organized more over last few months. If things 
continue as they are now I should be able to be more active again.



Robert Martin wrote:
> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/Icesphere
> seems to be what website is availible
>
> hint for the developer
> 1 could you please get a website for this and not have your stuff
> scattered across 5 different sites
>
> 2 a patched build would be a good 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

[opensource-dev] Enabling Right-To-Left Glyphs for Windows

[Dzonatas Sol]

Until there is full bidi support built-in to the viewer, I've suggested 
for users to try Icesphere to allow them to type right-to-left.

There is already a language barrier in being able to communicate what 
needs to be done. I'm being asked for a Windows build of Snowglobe with 
the SNOW-375 patch applied. You can see here why:

http://twitpic.com/259h5y

The SNOW-375 patch is not being committed to the repository at this 
time. Should I ask for help from someone that can contact me to help 
build a Windows version of Snowglobe 2.x. I don't have Windows machine 
to build.

Is this intermediate solution of value?

I've only have a Linux build located here: 
http://code.google.com/p/icesphere/downloads/list

I'm closer to a version of this patch I would like to submit to the 
repository, so another solution maybe is to hang tight.

Thanks

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] Enabling Right-To-Left Glyphs for Windows

[Dzonatas Sol]

Thanks to Nicky Perian, we now have a Snowglobe-375 release for Windows

Available here for download: 
http://code.google.com/p/icesphere/downloads/list

This is for SNOW-375 version 0.10.2.0.

Setup for Icesphere is separate, yet maybe easier one day.


Dzonatas Sol wrote:
> Until there is full bidi support built-in to the viewer, I've 
> suggested for users to try Icesphere to allow them to type right-to-left.
>
> There is already a language barrier in being able to communicate what 
> needs to be done. I'm being asked for a Windows build of Snowglobe 
> with the SNOW-375 patch applied. You can see here why:
>
> http://twitpic.com/259h5y
>
> The SNOW-375 patch is not being committed to the repository at this 
> time. Should I ask for help from someone that can contact me to help 
> build a Windows version of Snowglobe 2.x. I don't have Windows machine 
> to build.
>
> Is this intermediate solution of value?
>
> I've only have a Linux build located here: 
> http://code.google.com/p/icesphere/downloads/list
>
> I'm closer to a version of this patch I would like to submit to the 
> repository, so another solution maybe is to hang tight.
>
> Thanks
>


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] Merges & Builds

[Dzonatas Sol]

Philippe (Merov) Bossut wrote:
>
> Cc-ing all list members as it is of general concern.

Thank you Philippe for your several hours of work on this merge for 2.1.

I can see there are a lot of changes since 2.0. Only if people could see 
statistics displayed on the UI, like one of those per source line 
counters that multiply development cost, just to see how much work goes 
into the viewer then they might see what we appreciate about all 
improvements made from 1.x to 2.x, and now 2.1. Then on-top of that, to 
see your dedication to get all these different changes to work nicely 
together.

Heck, I grip over a merge set that conflicts purely over whitespace. I 
don't even see you grip about this! You get it done! =p


Good job!







P.S. I think they should add merge composition to those per source line 
counters. =)

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] Build notices missing change data??

[Dzonatas Sol]

Do you mean the commit log?

http://svn.secondlife.com/trac/linden/log/projects



Robert Martin wrote:
> Is there any way to see what changed from build to build?? also does
> it seem like the build farm is triggering way to many times a day??
>
>   


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] SNOW-774 "Bad LLMultiGesture version" (SG2.0 works, SG2.1 errors)

[Dzonatas Sol]

Hi,

I have an issue I want to resolve.

http://jira.secondlife.com/browse/SNOW-774

This message I notice from time to time in the error log. You have 
probably noticed the message "Unable to load " where gesture is 
one of many you have activated.

There has been some change made between 2.0 and 2.1 that causes this, 
yet it is hard to pinpoint the difference among the bulk commits.

If no one replies to this then I'll assume it basically works for them.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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-774 "Bad LLMultiGesture version" (SG2.0 works, SG2.1 errors)

[Dzonatas Sol]

I believe I found the issue.

The difference is the asset is located in "static VFS" rather than 
normal "VFS".

The asset load returned file size 0 for an asset located in "static 
VFS", and so it couldn't deserialize.


Carlo Wood wrote:
> IF we had already hg (or git) instead of SVN, so we would
> really have every commit merged from viewer-external,
> then it would easy to find using a binary search method...
>
> I hope the move to hg is made soon, for many reasons.
>
> On Wed, Jul 28, 2010 at 12:16:29PM -0700, Dzonatas Sol wrote:
>   
>> Hi,
>>
>> I have an issue I want to resolve.
>>
>> http://jira.secondlife.com/browse/SNOW-774
>>
>> This message I notice from time to time in the error log. You have 
>> probably noticed the message "Unable to load " where gesture is 
>> one of many you have activated.
>>
>> There has been some change made between 2.0 and 2.1 that causes this, 
>> yet it is hard to pinpoint the difference among the bulk commits.
>>
>> If no one replies to this then I'll assume it basically works for them.
>>
>> -- 
>> --- https://twitter.com/Dzonatas_Sol ---
>> Web Development, Software Engineering, Virtual Reality, Consultant
>>
>> ___
>> 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
>> 
>
>   


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] Image Recognition

[Dzonatas Sol]

Hi,

I caught the tweet from Pamela Fox @ Google, and she linked a 
development for image recognization: http://developer.iqengines.com/

What stood out was how a UUID was included and some sort of description 
present. It's not gesture recognition through motion, yet even I can 
think of how this could apply well in Second Life at different levels.

I'm thinking of ideas from authentication to...  returning an "abstract" 
texture UUID for an object's face detected by a ray-cast, see my blog: 
http://icyspherical.blogspot.com/2010/07/optimizing-simulations-with-basic.html

 Any questions?

=) =) =)

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] Performance: 100%-150% increase in rendering

[Dzonatas Sol]

Hi,

I believe I found another solution.

In my research as I optimized graphics routines in the viewer, I 
achieved between 100% to 150% increase in rendering performance. To be 
fair, I reported as "up to 100%".

There overall frame loop has many tasks, so keep that in mind that 
overall performance increase noted are of tasks that directly related to 
rendering itself.

I was blackboxed from the results when deployed. I admit, it pissed me 
off how that was done, even if I had a right to be pissed, ... meh.

However, I found out that "shown" results were actually not even my 
fault. I even realize they aren't of the of fault of those who 
immediately  worked around with me on it. Of what little I had to work 
with, it didn't make sense, and the obvious thing was to "fix" it as a bug.

I think some of us realize it was no software bug. I can understand 
while the market plays to GPUs, that such any performance increase that 
would generally help everybody would be held back because of  
"overclockers".

I don't think it matters anymore, and no need to keep something that 
isn't a secret as a secret anymore.

Let's just say that I was visualizing how the "streaming media 
extensions" work through the hardware. Then I realized that the obvious 
answer was that "overclockers" were reporting problems yet they weren't 
telling they overclocked. The visualization I had led me to decide that 
is the logical explanation.

"Overclocking"... don't do that!  We have proven that the overall 
performance in rendering "sucks" for the larger general audience due to 
the "few" that report "knowledge" of their "crashes" from "overclocking" 
yet  those details aren't even being recorded even when fully not 
blackboxed.

Even where there is no crashes...  it is only a demostrations of where 
the GPU actuall fails... and not the CPU...  of course there is no 
crash. The GPU is preventing itself... it only overheats... hides itself 
and "BURN".

Enjoy!


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] Performance: 100%-150% increase in rendering

[Dzonatas Sol]

Was just thinking of a secondary proof to this. This should be helpful 
to traditional physicist: Dark Liquid Crystal.

The significant thing to note is how light "slows" or "refracts" as 
noted by dark matter... when taken to a substate.

On that note... it's not for me to "doctor" the Rx, and I know someone 
that wants...



heh... "BURN"...  love it!

Oh let's "share" this one... LMAO



P.S. Working On It 2.0...



Dzonatas Sol wrote:
> Hi,
>
> I believe I found another solution.
>
> In my research as I optimized graphics routines in the viewer, I 
> achieved between 100% to 150% increase in rendering performance. To be 
> fair, I reported as "up to 100%".
>
> There overall frame loop has many tasks, so keep that in mind that 
> overall performance increase noted are of tasks that directly related 
> to rendering itself.
>
> I was blackboxed from the results when deployed. I admit, it pissed me 
> off how that was done, even if I had a right to be pissed, ... meh.
>
> However, I found out that "shown" results were actually not even my 
> fault. I even realize they aren't of the of fault of those who 
> immediately  worked around with me on it. Of what little I had to work 
> with, it didn't make sense, and the obvious thing was to "fix" it as a 
> bug.
>
> I think some of us realize it was no software bug. I can understand 
> while the market plays to GPUs, that such any performance increase 
> that would generally help everybody would be held back because of  
> "overclockers".
>
> I don't think it matters anymore, and no need to keep something that 
> isn't a secret as a secret anymore.
>
> Let's just say that I was visualizing how the "streaming media 
> extensions" work through the hardware. Then I realized that the 
> obvious answer was that "overclockers" were reporting problems yet 
> they weren't telling they overclocked. The visualization I had led me 
> to decide that is the logical explanation.
>
> "Overclocking"... don't do that!  We have proven that the overall 
> performance in rendering "sucks" for the larger general audience due 
> to the "few" that report "knowledge" of their "crashes" from 
> "overclocking" yet  those details aren't even being recorded even 
> when fully not blackboxed.
>
> Even where there is no crashes...  it is only a demostrations of where 
> the GPU actuall fails... and not the CPU...  of course there is no 
> crash. The GPU is preventing itself... it only overheats... hides 
> itself and "BURN".
>
> Enjoy!
>
>


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] Performance: 100%-150% increase in rendering

[Dzonatas Sol]

Hi,

I understand your leading question.

It leads me to the conclusion that we should allow public Second Life 
Groups to automatically allow or disallow features within the client 
viewer architecture.

That probably doesn't make sense unless you read the source, yet there 
are so many people that don't read the source.

I started to think about a "Doctor" group, as in Science-of-the-Arts 
Doctor. I think universities may need such funding^B^B^B^B, especially 
if they own the group as a piece of content they create. It's not 
obvious, yet between Second Life land and a Second Life group the 
features already exist to create a certain desired flow.

It's like... i have a set of minimal features needed...  here is a 
larger set that provides them. It doesn't make sense to you unless you 
understand the minimal features needed.

Chat in those groups are optional, yet I think SL may want to consider 
group-chat-rates for real institutions and commercial businesses that 
reach a certain threshold.

Note that the significant feature here is the group acts as "flags" 
internally and externally to the source code... if you strip out what 
you know about chat and some other features. Start with that idea and 
catch-up... because we didn't have to change it.


Nexii Malthus wrote:
> ..What?
>
> - Nexii
>
> On Tue, Aug 3, 2010 at 4:44 PM, Dzonatas Sol  <mailto:dzona...@gmail.com>> wrote:
>
> Was just thinking of a secondary proof to this. This should be helpful
> to traditional physicist: Dark Liquid Crystal.
>
> The significant thing to note is how light "slows" or "refracts" as
> noted by dark matter... when taken to a substate.
>
> On that note... it's not for me to "doctor" the Rx, and I know someone
> that wants...
>
>
>
> heh... "BURN"... �love it!
>
> Oh let's "share" this one... LMAO
>
>
>
> P.S. Working On It 2.0...
>
>
>
> Dzonatas Sol wrote:
> > Hi,
> >
> > I believe I found another solution.
> >
> > In my research as I optimized graphics routines in the viewer, I
> > achieved between 100% to 150% increase in rendering performance.
> To be
> > fair, I reported as "up to 100%".
> >
> > There overall frame loop has many tasks, so keep that in mind that
> > overall performance increase noted are of tasks that directly
> related
> > to rendering itself.
> >
> > I was blackboxed from the results when deployed. I admit, it
> pissed me
> > off how that was done, even if I had a right to be pissed, ... meh.
> >
> > However, I found out that "shown" results were actually not even my
> > fault. I even realize they aren't of the of fault of those who
> > immediately �worked around with me on it. Of what little I had
> to work
> > with, it didn't make sense, and the obvious thing was to "fix"
> it as a
> > bug.
> >
> > I think some of us realize it was no software bug. I can understand
> > while the market plays to GPUs, that such any performance increase
> > that would generally help everybody would be held back because
> of
> > "overclockers".
> >
> > I don't think it matters anymore, and no need to keep something that
> > isn't a secret as a secret anymore.
> >
> > Let's just say that I was visualizing how the "streaming media
> > extensions" work through the hardware. Then I realized that the
> > obvious answer was that "overclockers" were reporting problems yet
> > they weren't telling they overclocked. The visualization I had
> led me
> > to decide that is the logical explanation.
> >
> > "Overclocking"... don't do that! �We have proven that the overall
> > performance in rendering "sucks" for the larger general audience due
> > to the "few" that report "knowledge" of their "crashes" from
> > "overclocking" yet �those details aren't even being recorded
> even
> > when fully not blackboxed.
> >
> > Even where there is no crashes... �it is only a demostrations of
> where
> > the GPU actuall fails... and not the CPU... �of course there is no
> > crash. The GPU is preventing itself... it only overheats... hides
> > itself and "BURN".
> >
> > Enjoy!
> >
>   

[opensource-dev] V2.X & V1.X support on the same machine

[Dzonatas Sol]

I can't keep secrets, so I get blackboxed. It bugs me there are perfect, 
or almost perfect, programs that just need to be turned around in a way. 
Too many people are stuck in a paradigm that to even think about it 
would create a paradox to them. Is that the meaning of paradyme in motion?

I think that means people are soon gonna realize that the spam has 
already started to be a problem where smarter filters don't work 
anymore. Just observing an email has already been a problem to spam 
others. They can't even tell the difference between a save button and a 
button that saves itself... adware.

We don't need smart filters. We need a dumb filter... with love!

On that note, I doubt support for MOAP as it exists now is going to 
last, yet there was an obvious other purpose if you read the source.

I know various solutions to this, and they all have the answer, yet I 
know people will want to walk their own path. My question is, should we 
collect a few more solutions?

As a kid, I loved playing go fish, and then gin, and then gin rummy, and 
rummy, and then rummykub. =)

Poker probably fits right between gin and gin rummy. MOAP is like gin 
rummykub with a pun.

There is an opportunity here with MOAP while it lasts, yet don't expect 
specific external protocol to last. I'm listening to many ideas everyone 
wants that it makes me feel not to change it at all, step on a few toes, 
and rip this from that, and put this big hated thing right there, and 
maybe sometime state there is only backword compatibility based on the 
libraries now compiled.

What's the difference?

How about:

1) Running both code bases on the same machine
2) Running precompiled linux binaries on windows machines "right there"
3) Apple?  I only hear about iPhones from them and not...

Do I really want to do the hard work by myself? Do I have to explain...

How about... do you want it right there...  or somewhere else?

How about turning around without even turning around? My secret...

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] V2.X & V1.X support on the same machine

[Dzonatas Sol]

Marc Adored wrote:
> I'm with you Bunny the last few messages haven't made hardly any sense
> at all. I know it has something to do with some card games, MOAP and
> apple but what do they all have in common and is it relevant to
> opensource-dev?
>
>   

For accessibility needs.

Actually, we did something the "server only" devs wanted.

Imagine VX.X source uploaded a texture to  opensim.
Then imagine that being downloaded to Radegast.
Then imagine it telling  users the description of the texture.

If there is any problems, I'll be sure to show the timeslice coLinux 
takes in between VX.X and webkit just to let them think thereafter what 
that meant. If that doesn't mean anything, then I've done what I have to 
do to protect your context.

However, google might translate that texture to GPL code  with image 
recognition.

They are concerned this is viral. I think that got that backwards. BSD 
is for students only.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] V2.X & V1.X support on the same machine

[Dzonatas Sol]

Opensource Obscure wrote:
> By the way, one can check if she got all list messages
> through the archives, that can be found by following
> the links in the footer.
>
> Opensource Obscure
>   

I would also suggest to read Google's policy and term and conditions 
very carefully.

If anybody can disagree, then I ask for your reply, but I think LL 
screwed over by themselves (not important to use who made who)... it is 
important to fix the issue.

They've had an adult grid that is suppose to be fast, easy,... and fun.

They've had an teen grid that is suppose to be ... easy... fast... clean?

Where is the family grid?

I wouldn't doubt Google had on their minds to someone increase LL's 
revenue by a billion US$ over time, yet I can see that doesn't even 
match their protocol right now.

They could bring back gambling, banks, stock market, and so on... and 
just get rid of one idea that makes almost next dumbest nominate idea 
ever next to disposable baby plastic water bottles.

Sincerely,

___  Life



-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] Fixing the Assets

[Dzonatas Sol]

Here is the proposal, as a routine. The written logical explanation in 
English with normalized words defeats the purpose of the routine for 
every reason that supports it.

"Got to put a face on it:"

Store timestamp by UUID.
Keep secondary UUID to XOR with every second.
Doesn't matter if timestamp of UUID changes within that second, as long 
as one of the two changes.

That's a new "second".

Do that again for the new "minute" based on 60 new seconds.

The hour is optional, as there are several more value to consider to 
make a new "hour".

And so on, until you have decided on a new "timestamped UUID".

Store the original assets by Asset UUID or new timestamped UUID.

Don't transmit the original timestamp of the asset... only transmit the 
the newer created unique value.

The client-side can then create assets by that newer value, which would 
then create its own timestamp on the client side.

I think LL can figure out the rest...

Save yourself!

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] Fixing the Assets

[Dzonatas Sol]

If Linden Labs implements this much and Google thinks it is "clean", 
then maybe I'll smile again and show how to do folded execution...  and 
how to earn the money.

US open source "no-engine"ers aren't fools. We love magic, however.


Dzonatas Sol wrote:
> Here is the proposal, as a routine. The written logical explanation in 
> English with normalized words defeats the purpose of the routine for 
> every reason that supports it.
>
> "Got to put a face on it:"
>
> Store timestamp by UUID.
> Keep secondary UUID to XOR with every second.
> Doesn't matter if timestamp of UUID changes within that second, as 
> long as one of the two changes.
>
> That's a new "second".
>
> Do that again for the new "minute" based on 60 new seconds.
>
> The hour is optional, as there are several more value to consider to 
> make a new "hour".
>
> And so on, until you have decided on a new "timestamped UUID".
>
> Store the original assets by Asset UUID or new timestamped UUID.
>
> Don't transmit the original timestamp of the asset... only transmit 
> the the newer created unique value.
>
> The client-side can then create assets by that newer value, which 
> would then create its own timestamp on the client side.
>
> I think LL can figure out the rest...
>
> Save yourself!
>


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] Fixing the Assets

[Dzonatas Sol]

Oz Linden (Scott Lawrence) wrote:
>   On 2010-08-06 17:28, Dzonatas Sol wrote:
>   
>> Here is the proposal, as a routine. The written logical explanation in
>> English with normalized words defeats the purpose of the routine for
>> every reason that supports it.
>> 
> Clarity is never wasted.
>
> You have not given any hint at all as to what problem you are trying to 
> solve - without at least that, there is no way to even start thinking 
> about what you've written.
>   

Thanks!

Sometimes the concept is never understood when the meaning to the word 
concept is not understood. If the content is money, it means nothing, to 
We, who appreciate the honey.

We use use the spoon to eat the honey.

Bend the spoon?

Easy.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] V2.X & V1.X support on the same machine

[Dzonatas Sol]

Dzonatas Sol wrote:
> They've had an adult grid that is suppose to be fast, easy,... and fun.
>
> They've had an teen grid that is suppose to be ... easy... fast... clean?
>
> Sincerely,
>
> ___  Life
>

I believe I found a solution.

The svn code should be for only "kids"... even people who decide to make 
their avatars like "kids"... so a split code base "right there" where 
the more known "adult" possibility can be found in the hg repository.

I think that provides several options to get LL out of its corner.

We know there is confusion between "shared" code base and "split" code 
base... yet we understand this.

It's the same feel... they need to earn it to grow up... but its got to 
be their choice to know what they lost. Some have already taken that 
choice...

.. they just haven't quite... you know.

-- "."  [Fixt.]





-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] 1.4 Showstopper: SNOW-799

[Dzonatas Sol]

Hi,

I had to think about what what untamed HTTP textures could do on the teen.

/. had this article to say today: 
http://yro.slashdot.org/story/10/08/06/150216/Child-Porn-As-a-Weapon


/"Want to get rid of your boss and move up to his position? Put kiddie 
porn on his computer then call the cops! This was the cunning plan 
envisaged by handyman Neil Weiner of east London after falling out with 
school caretaker Edward Thompson too many times. Thankfully, Weiner 
didn't cover his tracks quite well enough to avoid being found out 

 
— earlier boasts about his plan to friends at a BBQ provided the police 
with enough evidence to arrest him for trying to pervert the course of 
justice. Frighteningly, however, between being charged with possession 
of indecent images and being exonerated, innocent (if 'grumpy') Thompson 
was abused and ostracized for eight months 

 
by neighbors and colleagues. With computer forensics for police work 
often being performed by 'point 'n click'-trained, nearly-retired cops, 
or languishing in a 6-month queue for private sector firms to attend to 
it, the uncomfortable question is raised: how easily might this trick 
have succeeded if Weiner had been a little more intelligent about it?"


/Consider that I have known the internet completely untamed since a 
young age ...  where does it begin to start to be accepted as "virgin"?

Was it a contrite decision? Or, a luxury?

I look at the world as if I'm looking into a vanity mirror... you decide.




Aleric Inglewood wrote:
> Please your attention for http://jira.secondlife.com/browse/SNOW-799
>
> The only reason I can currently think of that this might not be a 
> showstopper is when
> it is caused by having 'Use HTTP textures' turned on... but shouldn't 
> that be working with 1.4?
>
>
> 
>
> ___
> 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


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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