Re: [opensource-dev] Review Request: Modify Viewer to statically link to KDU v6.4.1 if available

[Tateru Nino]

Basically, if you build a viewer, you can't include KDU in it, unless 
you have a license to do so. Assuming that you *do* have a license to do 
so, you cannot then distribute that viewer to any other person unless it 
is allowed by that license.


Linden Lab doesn't - insofar as I am aware - have a license that allows 
it to distribute any of the code to us or to anyone else - therefore, 
any viewer you build based off the code-base that supports static KDU 
linkage can't be built - by you or me or anyone - to include KDU 
statically, unless you've purchased a license from Kakadu.


tl;dr: No KDU for you, unless you pay Kakadu for it. You will have to 
build with an alternative JPG2K library, otherwise.


On 5/12/2010 3:34 AM, Ponzu wrote:
A question about the static KDU issue.  I believe this means that when 
I do a build on my local machine, I do NOT have a KDU license.  Is 
that true?  Or, do I somehow inherit rights from Linden Lab?


ponzu


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


--
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Any hope of STORM-727 getting a little love?

[Tateru Nino]

I'd generally grade that as a showstopper. Anything that needs the user 
to relog or restart to restore normal functionality is, essentially, 
requiring the user to restart their show. It's a showstopper for the user.

On 8/12/2010 3:45 AM, Dave Booth wrote:
> It's graded "Minor" but I really think it falls into the "Major"
> category - Functionality is seriously broken (landmark creation) and the
> only workaround is to relog. I also think its importance is increased by
> the fact that v2 (and this bug has been around since 2.0) is supposed to
> provide a "better new user experience" and this is a bug that will most
> seriously impact new users. It's minor for longtimers who already have a
> well populated and pretty static folder of landmarks but for new users
> having the places tab cease functioning every time they create a
> landmark is a much more significant impact.
>
> Dave.
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] What happened to Joe Linden?

[Tateru Nino]

Not the right place to ask. Joe's left, that's all I know at the moment: 
http://bit.ly/e3JsjY

On 24/12/2010 5:16 PM, k\o\w wrote:
> I just noticed that Joe Miller was stealthily removed from the Linden
> Management page within the last week.
>
> Anyone know what happened to Joe? Who is the new/interim VP of
> Technology&  Platform development?
>
> If Joe has indeed left the lab, he'll be greatly missed! He was one of
> the few managers at Linden who really understood the technology and
> would reignite my confidence in the company when he participated in the
> sl dev discussions.
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Anyone playing with Android and Second Life?

[Tateru Nino]

On 29/12/2010 2:57 AM, Robin Cornelius wrote:
> On Tue, Dec 28, 2010 at 3:55 PM, Robin Cornelius
>   wrote:
>
>> The other issue is, if they are using a central server to perform the
>> connection to SL then transmitting revelant data to your handset,
>> unless they have been very clever to avoid TPV clause 2.e, and it
>> seems to be this that is mentioned in the linked discussion, then that
>> would be considered a serious issue by LL, even if they had all good
>> intentions.
> And in the worst possible email etiquette, replying to ones self..
>
> Their changelog says
>
>   v1.13.852
> * the whole login process is now handled by the mobile device itself,
> from now on no passwords nor their hashes are transfered to our
> servers.
>
> So that avoids 2.e
I'd be more concerned about capabilities URIs, myself. The login 
credentials are only the front-gate.

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Anyone playing with Android and Second Life?

[Tateru Nino]

On 29/12/2010 3:12 AM, Robin Cornelius wrote:
> On Tue, Dec 28, 2010 at 4:05 PM, Tateru Nino  wrote:
>
>>> So that avoids 2.e
>> I'd be more concerned about capabilities URIs, myself. The login
>> credentials are only the front-gate.
>>
> Thats absolutly true, and it would be trivial to inject a pay packet
> or any other packet into the data stream. But its probably far far
> easier to place malicious code in a TVP binary. So unless you are
> going to download the source to a TPV and diff it against LL code
> base, then compile yourself (ensuring all dependencies are also
> provided by LL/built by yourself), are you really any more at risk? ,
> i'm just being a bit of a devils advocate here, my first comments were
> a literal comparison of if they met the TPV rules for listing.
Ultimately it all comes down to trust, yes - regardless of who provides 
the application.

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Convexdecomposition for open source devs

[Tateru Nino]

Knowing what their licenses are is very important. They'll need to be 
LGPL compatible, if I remember rightly.


On 31/12/2010 1:03 AM, WolfPup Lowenhar wrote:


I have recently had a conversation with someone @ LL that has said 
they would be willing to help develop and OS version of 
llconvexdecompisition. I even I even discussed which ones they thought 
was good but they have not had the time to look at the open source 
version in a technical way. So what I thought of is start a thread 
here that would allow the OS community both vote and comment on the OS 
versions with the one most generally liked being used and converted to 
be compatible to the LL mesh viewer.


Versions that I have found(to place your vote on this put an x next it.):

Bullet Physics Library(just the convexdecomp section):

Web site : http://code.google.com/p/bullet/

Votes>


  John Ratcliff's <http://codesuppository.blogspot.com/>:


  Web Site :
  
http://codesuppository.blogspot.com/2009/11/convex-decomposition-library-now.html


  Votes>


  Comments for either system:



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


--
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Exclude Home from teleport history

[Tateru Nino]

On 3/01/2011 12:03 PM, laurent.bec...@madonie.org wrote:
>
> Erin Mallory a écrit :
>> I would really really rather not see home excluded because of the
>> simple fact often home lotation can get reset if your preferences get
>> changed or any of a half dozen minor bugs.  so its nice to have it in
>> the hisotry so you can go back and set it back.
> I've never seen that. Did it happened to you already ?
I've had it happen to me before also. There's a couple things that can 
silently reset your home location.  For a while, some people were 
triggering it intentionally as a way of evading parcel ejection and so 
on - sure the owner can try to send you home, but if your home is where 
you are, nothing happens.

At least one of the methods (which can happen unintentionally) was 
repeatedly reported as a security exploit back in 2006 - but AFAIK, it's 
still unfixed.

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Inventory incremental search (VWR-23712)

[Tateru Nino]

On 5/01/2011 11:39 PM, Lance Corrimal wrote:
> Am Mittwoch, 5. Januar 2011, 13:24:14 schrieb Oz Linden (Scott Lawrence):
>> On 2011-01-05 6:13, Lance Corrimal wrote:
>>> Isn't the acceptance of the contribution agreement automatically implied
>>> when you upload a patch to a jira?
>> Alas, no.   Putting a patch on jira, this list, or the codereview site
>> means that it falls under any agreement that you have executed, but
>> actually executing the agreement must be explicit.
> from the jira:
>
> "All submissions to this site are governed by Second Life Project Contribution
> Agreement. By submitting patches and other information using this site, you
> acknowledge that you have read, understood, and agreed to those terms."
>
> I understood that as "if you post anything here you automatically state that
> you agreed to the contrib agreement"... which is kind of a rat trap clause
> since throughout their SL almost anyone posts "other information" on jira at
> some point...
I think the implication of it is that you're acknowledging that you've 
already submitted a contribution agreement. However, things have been a 
bit lax and I understand there's more than one patch that has made it 
into the viewer - since the contribution agreements started - without 
any actual agreement on file.

Ideally, someone should cross-check all of the contributed patches 
against the agreements. Sounds like a good job for someone on the legal 
team.

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Inventory incremental search (VWR-23712)

[Tateru Nino]

On 5/01/2011 11:57 PM, Stickman wrote:
>> what about someone from marketing, about time they did someone useful... :P
> Just throw the task to support. I'm sure they're not busy with anything else. 
> :D
>
Come on folks :) Let's not take the opportunity to have a dig (though, 
yes, I agree it is tempting, but perhaps not appropriate to this list).

I think it's important for everyone that *someone* sit down with those 
agreements and make an effort to find where the legal rights and 
provenances of the viewer code have been tainted. Who better than the 
folks who wrote the agreements up and who know just how serious that is?

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Pre-processing chat input (was Re: Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages

[Tateru Nino]

Which is a shame. It's significantly less versatile that way.

On 13/01/2011 12:06 AM, Nexii Malthus wrote:

"/me " is a *post-process*.

- Nexii

On Sat, Jan 8, 2011 at 7:16 PM, Jonathan Welch <mailto:jhwe...@gmail.com>> wrote:


Yesterday it was suggested to substitute /me at some early point.

In this particular case it would not work for two reasons:

1) "/me" has to pass through the communications system so when it
arrives at the viewer from the server the various components that
display the line can see it is a "/me" line and insert the name in
italics or otherwise "do the right thing".  You have local chat
toasts, chat history, the IM window, etc.

2) There are 3 ways messages can arrive from objects (llSay,
llOwnerSay, and llInstantMessage) so there is no way they can be
processed until the arrive at your viewer for display.

-Jonathan
___
Policies 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


--
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Pre-processing chat input (was Re: Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages

[Tateru Nino]

On 13/01/2011 2:17 AM, Jamey Fletcher wrote:
> Tateru Nino wrote:
>
>>Which is a shame. It's significantly less versatile that way.
>> On 13/01/2011 12:06 AM, Nexii Malthus wrote:
>>> "/me " is a *post-process*.
> I'm missing what versatility we're wanting in /me - I've always seen it
> as a rather straight-forward substitution.
>
Well, using myself for an example, I'm used to using a completely 
different set of tokens and substitutions for that sort of thing. I 
think SL is the only thing I use that supports the old IRC syntax. I 
find it awkward, and it would be nice to be able to use conventions that 
are more common to the software that I use. As a post-processed 
substitution token, though, I just don't have the luxury to use familiar 
textual communication modes.

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Slightly off topic but need ideas how to fix

[Tateru Nino]

On 14/01/2011 7:13 AM, Altair Sythos Memo wrote:
> On Thu, 13 Jan 2011 11:17:27 -0500
> Erin Mallory  wrote:
>
>> This is slightly off topic but as the ramifications of what will
>> happen when the old profiles are taken down is starting to get out
>> there, merchants and content creators are starting to panic about
>> what these new profiles mean for them. There is a a ton of content
>> that is going to be broken by this, much of it content that
>> businesses rely on heavily. a more full list can be found in web-3509
>> but a number of rewards systems, venders, and security devices found
>> within hundreds if not thousands of SL stores are built heavily
>> around the old profile pages and cannot be easily updated or replaced
>> before the old profiles will likely be taken down... Even if
>> businesses begin to switch over, that involves changing out sometimes
>> hundreds of venders, everything associated with the venders (like
>> gift cards etc), and during all of that the ability to make new
>> content is affected. Many SL businesses are teetering on the edge of
>> bankrupcy already, including many where this is the SOLE or largest
>> percentage of income to those that simply are incapable of getting an
>> income any other way. So I'm pleading with the lindens and devs on
>> this list to PLEASE start putting some thought to how to mitigate
>> this...
> i'm sorry but don't understand how web interface to show profile data
> can involve business. scripts still work in both directions
> (groups, key2name, the new istr about display names), and web interface
> is just a re-design of the "old" profile in sidebar (upper piece
> SL-photo +SL desc, just under RL photo +info, on a sie groups and
> picks), is just a interface design... you can stil ask for friendship,
> open an IM, offer a teleport, invite to a group (and bot can still
> invite to groups), so how shops, security systems and other can be
> involded by web profiles?
>
Some businesses used the presence of picks to their locations in a 
user's profile as a method of gaming the search system, and set up 
scripts that would scrape the previous version web-profiles for data 
about whether a particular person had those picks on their profile and 
autopay them trivial amounts for it if they kept the picks for a long 
enough period.

Since my understanding is that picks don't affect search-results 
any-longer, however, I don't see that as a huge problem. Some businesses 
still keep the practice up, however, believing that it still works.

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] X network test dump (capacity failure)

[Tateru Nino]

It's okay. We already go 
through your trash in the middle of the night, anyway. Incidentally, 
you're out of cheese.


On 15/01/2011 12:57 PM, Joshua Bell wrote:
On Fri, Jan 14, 2011 at 4:20 PM, Joshua Bell <mailto:j...@lindenlab.com>> wrote:





{"deviceId":"4d30a642a56f04.90158583","userAgent":"Mozilla/5.0
(Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML,
like Gecko) Chrome/9.0.597.47

Safari/534.13","href":"http://interest.secondlife-staging.com/landing/s/chat?
<http://interest.secondlife-staging.com/landing/s/chat?rerun>


Oops, sent that to the wrong mailing list.

FYI, that's just a dump of script data from a browser trying to access 
the Second Life Web Viewer Beta, nothing secret. If you're trying out 
a session you can get at the same data by groveling around in the Web 
Inspector console or Firebug.


Careful observers will now know what city I'm in and what OS/browser 
I'm running, though. Eeeek! :)


-- Josh


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


--
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Review Request: VWR-24317: Fix of debug warning (printing of unassigned variable)

[Tateru Nino]

I confess to not liking leaving in incorrectly spelled commented code. 
Just saying.


On 17/01/2011 11:31 PM, Oz Linden wrote:
This is an automatically generated e-mail. To reply, visit: 
http://codereview.secondlife.com/r/87/



indra/llui/llnotifications.cpp 
<http://codereview.secondlife.com/r/87/diff/1/?file=407#file407line1384> 
(Diff revision 1)

void replaceSubstitutionStrings(LLXMLNodePtr node, StringMap&  replacements)
1384
//llwarns<<  "replaceSubstituionStrings: value: "<<  value<<  " 
repl: "<<  replacement<<  llendl;
1384
//llinfos<<  "replaceSubstitutionStrings: value:\""<<  value<<  "\"  
repl:\""<<  replacement<<  "\"."<<  llendl;

I don't like leaving in commented-out code.

I would prefer that this either be changed to a debug level message or deleted.

- Oz


On January 14th, 2011, 12:56 p.m., Aleric Inglewood wrote:

Review request for Viewer.
By Aleric Inglewood.

/Updated Jan. 14, 2011, 12:56 p.m./


  Description

Fixed a typo that I stumbled upon and added quotes,
and changed the warning to print something that makes
more sense ('replacement' is always empty, since we
didn't find it!)

*Bugs: * VWR-24317 <http://jira.secondlife.com/browse/VWR-24317>


  Diffs

* doc/contributions.txt (b0bd26c5638a)
* indra/llui/llnotifications.cpp (b0bd26c5638a)

View Diff <http://codereview.secondlife.com/r/87/diff/>


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


--
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] STORM-243 - simulator version notifications

[Tateru Nino]

Speaking as an unrepresentative sample of... err... one, I find the 
popup very useful - but *only* in certain defined periods where I am 
intending that it be an important part of what I'm doing (and it 
sometimes is). At that point, I *would* like more detail (exactly what 
version am I arriving in and what version have I arrived from). The rest 
of the time - being 99.5% of the time, I'd prefer it to default to off, 
and not see the popup at all.

On 19/01/2011 2:22 AM, Kent Quirk (Q Linden) wrote:
> Hi, folks. I've just commented on STORM-243, which requests that we have Yet 
> Another Option to allow suppression of the toast that tells you the simulator 
> version changed when you changed to a new region.
>
> I think we should delete it entirely. Does anyone care to still get that 
> notification, now that there are usually 3 different simulator versions live 
> on the grid at any time? I don't mean "I can think of an obscure scenario 
> when someone might care." I mean does anyone really need a notification about 
> this, or can we just delete 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
>

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] STORM-243 - simulator version notifications

[Tateru Nino]

Well, connect up the network message system with a small plugin stub in 
python or something, expose the popup API to it, and I'm sure we can 
each decide for ourselves what events and messages should and shouldn't 
generate popups and under what circumstances. Then, perhaps, we could 
expose a few more APIs like chat/chat-history - as an example.

On 19/01/2011 3:00 AM, Kent Quirk (Q Linden) wrote:
> Everyone wants more options. Why should this be an option?
>
> Just because you're interested in knowing the version number, do you really 
> need a notification of it? What does that give you that checking About Second 
> Life doesn't give you?
>
> On Jan 18, 2011, at 10:40 AM, Opensource Obscure wrote:
>
>> I guess most people on this list are personally interested in that
>> notification. Still, I think we're a very non-representative sample
>> of the whole SL userbase - especially with regards to tech details.
>>
>> Off by default, with freedom to choose would be the best;
>> a Debug Setting would probably be good enough (since interested
>> people are "techie" enough to know how to get there);
>> should I choose between yes/no I would say "no" - remove them as
>> most SL users aren't interested in that information and/or don't know
>> what it means.
>> IMO
>>
>> Opensource Obscure
>>
>> On Tue, Jan 18, 2011 at 16:22, Kent Quirk (Q Linden)  
>> wrote:
>>> Hi, folks. I've just commented on STORM-243, which requests that we have 
>>> Yet Another Option to allow suppression of the toast that tells you the 
>>> simulator version changed when you changed to a new region.
>>>
>>> I think we should delete it entirely. Does anyone care to still get that 
>>> notification, now that there are usually 3 different simulator versions 
>>> live on the grid at any time? I don't mean "I can think of an obscure 
>>> scenario when someone might care." I mean does anyone really need a 
>>> notification about this, or can we just delete 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
>

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] STORM-243 - simulator version notifications

[Tateru Nino]

t; >> Date: Tue, 18 Jan 2011 08:35:01 -0800
> >> From: missannoto...@yahoo.com <mailto:missannoto...@yahoo.com>
> >> To: q...@lindenlab.com <mailto:q...@lindenlab.com>;
opensource-dev@lists.secondlife.com
<mailto:opensource-dev@lists.secondlife.com>
> >> Subject: Re: [opensource-dev] STORM-243 - simulator version
notifications
> >>
> >> Doesn't it add some minor overhead to region crossings? I
don't care about
> >> it. The message does not say what server version you just
entered so it is
> >> mostly an annoyance. If I need version info I know where it is.
> >>
> >> What I would like to see is region rating and a single letter
server version
> >> code on the map without having to mouse float.
> >>
> >> 
> >> From: Kent Quirk (Q Linden) mailto:q...@lindenlab.com>>
> >>
> >> Hi, folks. I've just commented on STORM-243, which requests
that we have Yet
> >> Another Option to allow suppression of the toast that tells
you the
> >> simulator version changed when you changed to a new region.
> >>
> >> I think we should delete it entirely. Does anyone care to
still get that
> >> notification, now that there are usually 3 different
simulator versions live
> >> on the grid at any time? I don't mean "I can think of an
obscure scenario
> >> when someone might care." I mean does anyone really need a
notification
> >> about this, or can we just delete 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
> >>
> >>
> >> ___ Policies 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
>
> ___
> Policies 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


--
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Need Clarification on interfacing with web-based UI elements

[Tateru Nino]

Seems to me that as more of that goes Web-side it needs more 
comprehensive standardization, documentation and versioning.


On 2/02/2011 2:36 PM, Arrehn Oberlander wrote:
This is an open question I've tried to ask at a few different linden 
office hours, but haven't yet received a response one way or the other.


There's a couple different viewer UI elements now in the pipeline that 
are effectively full web pages- the search window, and now the profile 
window. It seems like there is more to come.


As a community developer interested in customizing that user interface 
for particular audiences, can LL clarify a best practice for working 
with these elements?


From a glance it appears that the presentation info and data model are 
commingled, complicating client-side customization of the presentation.


It may be possible to scrape out data, but unmanaged minor server-side 
adjustments to the presentation page may break scraping activity 
suddenly without warning. For an example of this, one can look at the 
number of times LSL scripts which display profile pictures by scraping 
UUID's from web lookups have been broken over the last few years.


I'm hoping that LL can clarify which interface a community developer 
can use to request and retreive this web-based data, particularly for 
avatar profile page information, that will not be prone to casual 
breakage after a third party viewer has been released.


Thanks, and my apologies if the answer for this is someplace obvious 
I've overlooked.




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


--
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Is 'STANDALONE' confusing?

[Tateru Nino]

Or USE_LOCALLY_INSTALLED_LIBS even.

On 23/02/2011 3:04 PM, Erin Mallory wrote:

"> The real distinction, I think, is whether or not you are using
> _installed_ libraries. "

how about USE_INSTALLED_LIBS then? or possibly USE_LOCAL_LIBS

> Date: Tue, 22 Feb 2011 21:56:23 -0500
> From: o...@lindenlab.com
> To: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Is 'STANDALONE' confusing?
>
> On 2011-02-21 9:38, Boroondas Gupte wrote:
> > On 02/21/2011 03:28 PM, Oz Linden (Scott Lawrence) wrote:
> >> > If we are going to change it, the replacement term should, in 
addition
> >> > to being more accurately descriptive of what it does, be an 
affirmative

> >> > term - don't suggest any 'NO_*" replacements.
> > Would it be acceptable to invert the setting's semantic in order to
> > avoid a negation? I.e., STANDALONE=OFF would become NEW_SETTING=ON and
> > vice versa. That'd allow for easy-to-understand names like
> > USE_PREBUILD_LIBS or DOWNLOAD_NEEDED_DEPENDENCIES.
> >
> > Off course, the default value should be inverted together with the
> > setting's semantic, such that the default behavior does not change.
>
> Yes, I think that's best (assuming that we're going to change anything).
>
> A couple of comments on the interesting discussion
>
> I'm not sure that any variation on 'USE_PREBUILD' quite captures the
> correct semantics, because in the new autobuild framework one way to
> work is going to be to download the project for a library you want to
> compile locally (perhaps to try a new version, or to make some patch)
> and then modify your viewer builds to use the output of that
> compilation. When you do that, you'll still be using exactly the same
> sort of prebuilt package that you would, in the default case, download
> from LL.
>
> The real distinction, I think, is whether or not you are using
> _installed_ libraries. Normally, the viewer build has only minimal
> reliance on the libs that are installed on the system itself - it puts
> the packaged libraries (which are now by default all loaded in a
> 'build-*/packages directory rather than being mixed in with the 
sources).

>
> That might suggest something like USE_PACKAGED_LIBS with a default 
value

> of NO/FALSE.
>
> ___
> Policies 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


--
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Review Request: (STORM-380) There is a little delay in sound when gesture first time played

[Tateru Nino]

Notably, this doesn't actually improve things any for any observer
present when the gesture is triggered - but only for the user triggering
the gesture, right?

I presume any other party has no method of determining if animations and
sounds are being triggered as a part of a gesture or not. So, this only
affects the first (uncached) triggering, and only for the gesture
triggerer, am I right?

On 29/03/2011 6:21 AM, Seth ProductEngine wrote:
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/231/
>
>
> Review request for Viewer.
> By Seth ProductEngine.
>
> /Updated March 28, 2011, 12:21 p.m./
>
>
>   Changes
>
> Fixes according to the feedback on revision 1.
>
>
>   Description
>
> First pass implementation of syncing the animations and sounds before the 
> gesture starts playing.
> The actual playing of animations and sounds of a gesture starts only when all 
> needed animations and sound files are loaded into viewer cache. This reduces 
> the delay between animations and sounds meant to be played simultaneously but 
> may increase the delay between the moment a gesture is triggered and the 
> moment it starts playing.
>
> *Bugs: * STORM-380 <http://jira.secondlife.com/browse/STORM-380>
>
>
>   Diffs (updated)
>
> * indra/newview/llgesturemgr.h (b3cfba00a29b)
> * indra/newview/llgesturemgr.cpp (b3cfba00a29b)
>
> View Diff <http://codereview.secondlife.com/r/231/diff/>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Group Notices not getting delivered

[Tateru Nino]

On 1/04/2011 5:18 AM, Da5id Kronfeld wrote:
>
> On 2011-03-31, at 11:14 AM, Stickman wrote:
>
>> I've heard through the grapevine that only 400 random people in a
>> group larger than that get a group notice. But I have no information
>> from an authoritive source.
>>
>> I've suffered and seen many sufferers of non-received group notices.
>> So much so that people who need their messages received don't even
>> use group notices.
>>
>> Longstanding problem. No hope in sight. The bells. The bells!
>>
>> Stickman
>>
>>
>
> I have alts who are members of the same large groups and I see this
> all the time. Sometimes both, sometimes neither, and often just one
> account gets the notice.
>
Group notices become unreliable for large groups. I believe there are
ancient JIRAs about that. The issue dates back quite a ways. I'm not
aware of any *new* decline in group notice reliability at present, though.

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Intra-sim teleports and Local Chat History

[Tateru Nino]

On 7/04/2011 6:09 PM, Opensource Obscure wrote:
> On Sun, Mar 27, 2011 at 18:46, Opensource Obscure
>  wrote:
>> Which is the expected behaviour for intra-sim teleports
>> and Local Chat History? should these teleports show up,
>> like when you teleport to a different region?
>>
>> They currently don't, but they're correctly recorded in the
>> Teleport History in Sidebar.
>>
>> This is why I waited before closing
>> https://jira.secondlife.com/browse/VWR-15259 as Released.
>>
>> Note that it was filed against viewer 1.23, which lacked
>> sidebar, so chat history was the only place where teleports
>> could show up.
>> Still, the behaviour is different for intra-sim and extra-sim
>> teleports so I'd like to know if this is by design.
> Should I ask this question somewhere else? Where?
>
It seems like an appropriate venue to me. I get the feeling that the
non-orthogonality of it is something of an oversight - that intrasim
teleports follow a different code-path (which is to be expected, I
suppose), but that the asymmetry is the result of key code only being
added to the extra-sim teleport code-path.

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Review Request: STORM-1118 Viewer crashes when user tries to upload image without JFIF header

[Tateru Nino]

On 12/04/2011 9:31 AM, Vadim ProductEngine wrote:
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/255/
>
>
> On April 8th, 2011, 4:51 p.m., *Boroondas Gupte* wrote:
>
> indra/llimage/llimagedimensionsinfo.cpp
> 
> <http://codereview.secondlife.com/r/255/diff/2/?file=1426#file1426line97>
> (Diff revision 2)
>
> bool LLImageDimensionsInfo::load(const std::string& src_filename,U32 
> codec)
>
>
>   
>   97  
>
>   mInfile.seek(APR_CUR, 16);
>
> Magic number. (I guess it's BMP header (14) + DIB header - current 
> position (File begin + 2)?)
>
> Yep, pretty obvious. If I start documenting every line, code will eventually 
> look even worse than without comments.

That is what the documentation is for. The code can always be checked
against that.
>
> On April 8th, 2011, 4:51 p.m., *Boroondas Gupte* wrote:
>
> indra/llimage/llimagedimensionsinfo.cpp
> 
> <http://codereview.secondlife.com/r/255/diff/2/?file=1426#file1426line147>
> (Diff revision 2)
>
> bool LLImageDimensionsInfo::load(const std::string& src_filename,U32 
> codec)
>
>
>   
>   147 
>
>   mInfile.seek(APR_CUR, 8 /* chunk length + chunk type */);
>
> ... until here. (Assuming it's the same 8.) Might be worth another 
> constant.
>
> Come on, Boroondas, it wasn't difficult to find! ;-)
>
> On April 8th, 2011, 4:51 p.m., *Boroondas Gupte* wrote:
>
> indra/llimage/llimagedimensionsinfo.cpp
> 
> <http://codereview.secondlife.com/r/255/diff/2/?file=1426#file1426line217>
> (Diff revision 2)
>
>   
>
> bool LLImageDimensionsInfo::checkFileLength(S32 min_len)
>
>
>   
>   217 
>
>   char* buf = new char[min_len];
>
>
>   
>   218 
>
>   int nread = mInfile.read(buf, min_len);
>
>
>   
>   219 
>
>   delete[] buf;
>
> Wouldn't a seek be a "cheaper" way to determine size than reading 
> into an actual buffer? (According to indra/llcommon/llapr.h, it returns -1 on 
> failure.)
>
> There's also a static method LLAPRFile::size, but that seems to 
> operate on not-yet-opened files given by filename.
>
> seek() may go beyond the file end, so we can't use it to check whether the 
> file contains the needed header.
> Well, we could seek to the end of file, but accessing the whole file just to 
> find out that it's of wrong type looks like overkill.
> I agree that reading into a dynamically allocated buffer doesn't look nice, 
> but I think we can live with it as long as we only read small chunks this way.
>
> - Vadim
>
>
> On April 7th, 2011, 4:20 p.m., Vadim ProductEngine wrote:
>
> Review request for Viewer.
> By Vadim ProductEngine.
>
> /Updated April 7, 2011, 4:20 p.m./
>
>
>   Description
>
> * Added checks for image file contents not matching the file extension (e.g. 
> a bitmap named file.jpg).
> * Added checks for abnormally short files to avoid crashes when parsing them.
>
> *Bugs: * STORM-1118 <http://jira.secondlife.com/browse/STORM-1118>
>
>
>   Diffs
>
> * indra/llimage/llimagedimensionsinfo.h (33ca961b0870)
> * indra/llimage/llimagedimensionsinfo.cpp (33ca961b0870)
>
> View Diff <http://codereview.secondlife.com/r/255/diff/>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] How do I change the main background?

[Tateru Nino]

Is it possible that you're serving up an image, rather than an HTML page?

On 11/05/2011 11:23 PM, xinyi chen wrote:
> Hi, Guys:
>
> I'm trying to change the main background of Second Life Viewer2, I
> found the below code in indra\newview\llviewernetwork.cpp
>
> const char* DEFAULT_LOGIN_PAGE = "http://secondlife.com/app/login/";;
>
> Then I did replace the the variable DEFAULT_LOGIN_PAGE =
> "http://mysite.com/app/login/";;
>
> then re-build secondlife-bin.exe, when I run the exe, the main window
> doesn't display my web page ..
> The background is black only.
>
>
> Any ideas?
>
> Thanks in advance
> Simon
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] in-viewer translation is dead soon.

[Tateru Nino]

It's true - they're basically monetizing it. Incompletely, to be sure,
but that's better than killing the whole system.

On 29/05/2011 9:39 PM, Daniel wrote:
> You didn't read my previous comment apparently.  They are NOT shutting 
> off all translations.
> They are shutting the freestanding translation page in favor of embedded 
> translation web
> elements within pages.  The "why" is the freestanding page doesn't make 
> them any money,
> while translating web pages *which have Google ads included* gets more 
> readers for the ads,
> thus makes money.  That is entirely sensible from a business point of 
> view, although annoying
> for people used to using their service as it has been.
>
> For the built-in translator in recent viewers the choices are (1) delete 
> the feature, (2) find a
> way to use their web elements component, or someone else's service, or 
> (3) host translation
> software on LL servers so you are not dependent on the whims of a cloud 
> based service
> provider.
>
> On 5/29/2011 12:47 AM, Marc Adored wrote:
>> One thing I am
>> not sure about is why google is just shutting it down instead of
>> making the throttling permanent...
>>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Review Request: Viewer cache size increase to 10GB.

[Tateru Nino]

Not that I'm not glad to see the maximum cache size increased, but the
cache cap was only very reluctantly increased to 1GB as the performance
of the system increasingly suffered as the quantity of cached objects
increased.

How did we solve this?

On 4/06/2011 9:32 PM, Oz Linden wrote:
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/318/
>
>
> Ship it!
>
> - Oz
>
>
> On June 3rd, 2011, 12:56 p.m., Log Linden wrote:
>
> Review request for Viewer.
> By Log Linden.
>
> /Updated June 3, 2011, 12:56 p.m./
>
>
>   Description
>
> This patch increases the maximum and default viewer cache size values. Due to 
> limitations in the size of the VFS, the 80/20 texture cache/VFS split is 
> maintained up to 5GB, then the remaining cache size is given to the texture 
> cache. This caps the VFS size at 1GB ( up from .2 GB ).  I made corresponding 
> changes to the XUI to allow the slider to increase to the new cache size 
> maximum.
>
> Bugfixes:
> * The reset cache location button will no longer tell the user that the cache 
> will be cleared if the cache is already in the default location.  Only the 
> notification was suppressed, the cache was never cleared by this button 
> unless the location changed.
> * The reset cache location button will now correctly clear the old cache when 
> it is reset back to the default location. 
> * I fixed an order of operation programming error in an llerrs log message in 
> the lltexturecache.cpp. This was showing wildly incorrect texture cache size 
> during a purge.
> * Code convention cleanup in llappviewer.cpp in initCache() and 
> lltexturecache.cpp
>
>
>   Testing
>
> I have built and tested on all three platforms.  The log files indicate that 
> the caches are being initialised with the correct sizes.
>
> *Bugs: * er-767 , er-883
> , er-883
> 
>
>
>   Diffs
>
> * indra/newview/llappviewer.cpp (9c0506d10226)
> * indra/newview/llfloaterpreference.cpp (9c0506d10226)
> * indra/newview/lltexturecache.cpp (9c0506d10226)
> * indra/newview/skins/default/xui/en/panel_preferences_setup.xml
>   (9c0506d10226)
>
> View Diff 
>
>
> ___
> Policies 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] Review viewer -- draw distance slider

[Tateru Nino]

Use a tooltip for the text, and have it trigger as soon as the slider is
interacted with, and persist for several seconds after. That way,
there's informational text that follows the mouse cursor from the moment
the user starts interacting with it, until they stop - and several
seconds more.

That should give you the space for a concise (but not overly brief)
notification or explanatory message.

On 12/06/2011 9:08 AM, Jonathan Welch wrote:
> While testing the updated graphic I've been looking at the cautionary
> wording on the slider and am not happy with it.  There is no good way
> to align the text so it looks nice in all languages and the width of
> the slider would have to be wide enough to support the longest word in
> whatever language that happens to be.
>
> I am thinking that a warning notification message could be sent if the
> draw distance is adjusted up past a certain threshold.  Much more
> explanatory text could be put into this notice and it would also be
> i10n friendly.
>
> Warning: You have just set your draw distance to a large value.  This
> may cause poor system response.
> ___
> Policies 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] More proposals for draw distance slider icon

[Tateru Nino]

  
  
I'd consider a microscope to match the telescope.

On 14/06/2011 9:02 PM, Boroondas Gupte wrote:

  
  On 06/13/2011 02:44 PM, Carlo Wood wrote:
  
I think that no matter what you draw, the icon
will not be clear to the majority of people.

The icon only needs to be recognizable to those
who saw it before. They will have to learn
it's meaning from the tool tip imho.

Nevertheless, binoculars are usually used for
either zoom or search, so I think another icon
would be better.

Thinking about an avatar with a (half) sphere
around it, I'd use as icon a circle with a dot
in it, or a half circle with a vertical line
in the center, ie:
   _ - _
 .   .
   / O \
   --|--
  
  Here are some sketches I did based on Aleric's idea:
  


  
  Here are some ideas of my own:
  (Descriptions intentionally omitted, as we should not use the
  icons if they aren't recognizable. If you can't figure them out, I
  can tell you what I had in mind later on, in case someone wants to
  make better icons for the same concepts.)
  



  
  Cheers,
  Boroondas
  

___
Policies 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] Blocked

[Tateru Nino]

That's assuming they have the right kind of proxies there. HTTP proxies
are commonplace, but SOCKS proxies are far less common and more tightly
controlled on the corporate networks. He almost certainly has access to
the former, but maybe not to the latter.

On 15/07/2011 3:45 PM, Lance Corrimal wrote:
> Isn't it a good thing that there's a proxified viewer now... can 
> someone point him/her at the downloads for a build with the proxy 
> stuff?
>
>
> bye,
> LC
>
>
> Am Freitag, 15. Juli 2011 schrieb a...@skyhighway.com:
>> Robert,
>>
>> thx for the info, but i think the page is telling me the answer is
>> actually, "No," because i don't have any access to the company's
>> network stuff.  They look at you funny if you even ask about it. 
>> i can configure a test machine any way i want to, but i can't do
>> anything at all at all to the network.  How depressing :-(
>>
>> Since it is for a real work project, i think i'll show the page to
>> the IT guy, but i think this is just going to be another one of
>> those funny looks experiences, and a "I'll get back to you later"
>> that ends up being a not overly polite "helpful suggestion" from
>> my boss.  But i think it will be worth it just for the opportunity
>> of getting to explain what i'm doing.
>>
>> - AK
>>
>> On Thu, Jul 14, 2011 at 10:17 PM,   wrote:
 Hey y'all, i had something i wanted to do at work a coupla days
 ago
>> that i
>>
 coulda used SL for.  It installed, but i couldn't get it to
 connect.  Is there some kinda proxy setting that i need to fix
 to get SL to start from where i work?
>> short answer is yes
>> long answer is
>> http://wiki.secondlife.com/wiki/Configuring_your_firewall
>>
>> -- Robert L Martin
>>
>> ___
>> Policies 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] Call for mesh volunteer regions

[Tateru Nino]

Other objects. I 'lost' some sculptie items which were transformed into
toroids, when the code rolled out to my home sim - I'm on the mainland,
and my sim was randomly allocated to an RC channel at some point.

We spent hours speculating what could have happened to our stuff to
break it so badly.

On 3/08/2011 9:42 AM, Laurent Bechir wrote:
>
> I have a friend who is interested by this program. But I have some
> questions before. I read on the wiki :
>
> It is unlikely, but objects may be destroyed or broken permanently
>
> Does it concerns only meshes or also other objects rezzed on the sim ?
> I'm asking because the sim she wants to add in the beta program is
> where is her main store as fashion designer so I wondered if it was
> safe to be volunteer ?
>
> She is renting a sim. Can she asks herself to be volunteer or does she
> have to ask to the sim owner to do it ?
>
> Thank you 
>
>
> Le 2 août 2011 à 16:16, Oz Linden (Scott Lawrence) a écrit :
>
>>
>>
>>  Original Message 
>> Subject: Call for mesh volunteer regions
>> Date:Wed, 27 Jul 2011 16:14:55 -0700
>> From:Charlie (Charlar) 
>>
>>
>>
>> We're at about 100 regions right now - but we want to be at 300+ by
>> the end of the week.
>>
>> Now we want to accelerate the process, and to do that, we need more
>> volunteers. If you have a region, or know a good resident who has
>> one, the mesh team would love for you to volunteer it to run mesh.
>>
>> To understand the limitations (it can't be on the mainland, for one)
>> and find out how to get on the list, *go
>> to https://wiki.secondlife.com/wiki/Mesh/LiveVolunteers.*
>>
>>
>> Come live /La Vida Residente!/
>>
>> Charlie (Charlar)
>> ___
>> Policies 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] Collecting DIDN'T CRASH data

[Tateru Nino]

It's not a daft idea. It's good science.

On 9/08/2011 2:24 AM, Lee ponzu wrote:
> I just had a sort of strange idea, but maybe this is alrady common
> practice.  Just thought I would ask.
>
> Collect data about viewers that didn't crash.  After some time cutoff,
> send the didn't crash data (with permission of the user, of course) to
> a repository.
>
> Then, when you have a bunch of Crash Reports, you could compare them
> to the didn't crash reports from similar hardware/OS/Version, and
> maybe some pattern would pop out.  Such as VBO *and* AA crashes, or
> whatever.
>
> Just a thought.  Cannot stop my brain.  Best I can do is to not
> inflict it on everyone else too often.  You all owe me more than you
> know.  8-)
>
> ponzu
>
>
> ___
> Policies 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] Review Request: [STORM-56] As Builder, I want more decimal places allowed in the Build tool so that I can more precisely align small prims.

[Tateru Nino]

I know that there are certain minimums for position updates. If you move
a prim less than the threshold value it appears to move in the viewer,
but the region considers the prim *not* to have moved. I don't recall
exactly what the threshold value is - 0.005, I think. When you come back
to the region another time, the prim isn't exactly in the position you
thought it was in, as any updates below the threshold never 'took'.

That's one of several causes for so-called prim-drift (the prims look
like they're in the right place now, but later they're mysteriously not
quite where you think they should be).

My workaround for this has always been - that if I need to move a prim
such a small amount - to move it further away, and then apply the larger
delta to get it to where I needed it. That's always worked for me, even
to some quite fine levels of precision.

On 13/08/2011 4:54 AM, Kadah Coba wrote:
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/424/
>
>
> On August 12th, 2011, 10:09 a.m., *Richard Nelson* wrote:
>
> We picked the precision values for those spinners based on what would 
> survive the roundtrip via our precision-limited object update packets.  
> Adding more precision will possibly result in confusion when the values don't 
> respond the way you expect them to.  This is particularly a problem for 
> rotation...position and scale could probably survive another decimal 
> point...I haven't done the math.
>
> This would explain what Vadim found as I couldn't see what could be the cause 
> of that.
>
>
> Perhaps updating such small increments frequently, i.e. with the low 
> increment spinning, will led to small decimal accuracy being lost/ignored? 
> This was something I always wondered about. Phoenix and many other viewers 
> far older than it (I've only propagated the feature :P), had been using the 
> extra decimals without any apparent problems. But that mag vector of 1/2 
> millimeter seemed to be there for more than just limiting the number of sent 
> updates.
>
> During one of the iterations of porting this to v-d, I had an XUI property 
> for limiting the minimal increment of the spinner buttons. Lower decimal 
> values could still be entered but they could not be "slid" to. So if changing 
> an objects rotation, position or scale by an extra decimal or two 
> occasionally and intentionally, by manually entering it, isn't a problem or 
> too much of one, I could limit the spinner's minimum increment to the 
> original default lowest decimal place, or a multiple there of.
>
> - Kadah
>
>
> On July 29th, 2011, 4:40 p.m., Kadah Coba wrote:
>
> Review request for Viewer.
> By Kadah Coba.
>
> /Updated July 29, 2011, 4:40 p.m./
>
>
>   Description
>
> Adds 2 features:
>
> Adds the ability to use modifier keys to change the defined increment on 
> LLSpinCtrl.
> Alt: increment x10
> Ctrl: increment x0.1
> Shift: increment x0.01
>
> Adds extra decimal places to position, size, and rotation on build floater.
> Also changes LLPanelObject::sendPosition and LLPanelObject::sendScale to set 
> smaller changes in the associated values, no change was needed for 
> LLPanelObject::sendRotation. There should be no ill effects from this, 
> changes are still only sent to sim on button release.
>
> https://bitbucket.org/Kadah_Coba/storm-56
>
>
>   Testing
>
> Same code has been in use on FS beta for some time. I have built and tested 
> this myself on v-d.
>
> *Bugs: * STORM-56 
>
>
>   Diffs
>
>   * indra/llui/llspinctrl.cpp (UNKNOWN)
>   * indra/newview/llpanelobject.cpp (UNKNOWN)
>   * indra/newview/skins/default/xui/en/floater_tools.xml (UNKNOWN)
>
> View Diff 
>
>
>
> ___
> Policies 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] Current status of Mesh??

[Tateru Nino]

On 1/09/2011 4:30 AM, Lance Corrimal wrote:
> Am Mittwoch, 31. August 2011 schrieb Kadah:
>
>>> 2 are there any simple tools to make models (Blender does not
>>> qualify).
>> None that I know of.
>
> without having tried any of them I believe maya and google sketchup 
> work too, but don't ask me if they are easy to use or not.
Wings3D is my personal favourite mesh-modeller for beginners.
___
Policies 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] Current status of Mesh??

[Tateru Nino]

On 1/09/2011 4:08 PM, Marine Kelley wrote:
> On 31/08/2011, Robert Martin  wrote:
>
>> 2 are there any simple tools to make models (Blender does not qualify).
> Why doesn't Blender qualify ?
Blender's simpler than most 3D modelling applications (as a modeller),
but most folks have the impression that it is among the most complex. As
a result of that impression, few ever take the time to discover otherwise.

The fact that its UI layout is... unusual compared to most other
applications counts against it - which in itself is a lesson for us all.
___
Policies 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] ok wtf is this?

[Tateru Nino]

On 5/09/2011 3:27 PM, Dave Booth wrote:
> With the latest build I keep getting an alert box for "memory pool low, 
> some sl functions disabled to avoid crash" and sure enough I crash a 
> couple minutes later..   but memory pool low?  I've usually got over 2g 
> of physical memory free when it hits, and the machine isnt even breaking 
> a sweat. I dont see a ramp up in memory use that might indicate a leak, 
> I look at the logs and I see the latest ERROR level entry is a "bad 
> memory allocation" for a texture. Somebody who's more current with the 
> code tell me where I should look to narrow this thing down enough to 
> file a JIRA...
A "bad memory allocation" could be indicative of a corrupted heap - or
of a badly fragmented heap causing an otherwise easy allocation to fail.

... after a few moments of additional reflection, it could be that the
texture header data itself is corrupt, and the system thinks that it
needs to make an absurdly large memory allocation.

In order of likelyhood (most to least), I'd say: corrupted texture
header data, corrupted heap, fragmented heap.
___
Policies 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] ok wtf is this?

[Tateru Nino]

On 5/09/2011 4:47 PM, Dave Booth wrote:
> On 9/5/2011 12:53 AM, Tateru Nino wrote:
>
>> In order of likelyhood (most to least), I'd say: corrupted texture
>> header data, corrupted heap, fragmented heap.
>>
> After a few moments of reflection of my own, I agree with your 
> assessment..  The question that springs to mind is why does it happen in 
> an area where I know all the textures have been loaded successfully in 
> previous builds without any of the three issues showing up?
All bets are off with a heap-corruption bug. You might have clicked
twice, in rapid succession, on a UI widget with a non-reentrant handler,
or you might have viewed some _other_ content at some prior time during
the session which caused an allocation overrun. Whatever causes the heap
to mess up lays around like a time-bomb waiting for the allocator's pool
manager to discover that things are "messed the hell up".

Heap-corruption bugs are a pest, since there's usually little or no
relation between where the app fails and where the bug _really_ is. It
might even be easily reproducible - but that doesn't necessarily narrow
it down any, alas.
___
Policies 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] ok wtf is this?

[Tateru Nino]

On 6/09/2011 1:57 AM, Dave Booth wrote:
> On 9/5/2011 2:32 AM, Nicky D. wrote:
>
>> There is a memory pool that got enabled 4 days ago. Which could cause
>> this problem aswell.
>>
>> The change is here:
>> https://bitbucket.org/lindenlab/viewer-development/changeset/298722ecdb2e
>>
> oh yeah, that's an "aha!" moment for sure.. Thanks, Nicky.
>
> Checking the "changes since last good" on the download page there it is 
> on build 239990, the most recent, which correlates exactly with when I 
> started to see this failure mode. If switching it off means I dont crash 
> at all tonight then I'll leave a little gift on JIRA for the kindly 
> folks at the lab to discover after their long weekend :)
>
Indeedy. An excellent catch. If it _is_ the memory pool, though, it is
hard to figure out why unit-testing didn't catch the underlying fault.
___
Policies 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] An Idea

[Tateru Nino]

On 25/10/2011 12:54 AM, Garmin Kawaguichi wrote:
>> - Original Message - 
>> From: Dahlia Trimble 
>> Sent: Monday, October 24, 2011 4:08 AM
>> Subject: Re: [opensource-dev] An Idea
>> 1) open map
>> 2) zoom out all the way
>> 3) double click somewhere
>> works for me :)
> :))) For me too!!!
That's how I do it. Semi-random 'drunkard-walk' teleports are a
favourite pastime of mine.

___
Policies 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] Camera UI in Second Life beta viewer is broken

[Tateru Nino]

On 20/11/2011 2:26 PM, Laurent Bechir wrote:
>
> I did the refresh. The problem is not there. The problem is that when
> I click on a button (Save, Cancel, or another) the viewer react like
> if I was clicking behind it. For example, if the background of the
> picture window is the ground, clicking on a button is going to make
> move my avatar instead of the action the button is supposed to do. The
> is a turnaround for such buttons as Save to my inventory which consist
> on clicking on the part which is above the sidebar. But since Save and
> Cancel buttons are not above this part, they are unusable. I hope I'm
> more clear :)
>
Ahhh, I've seen this problem before! On a number of occasions, in fact.

It first started manifesting in the UI code in ... I think it was viewer
1.9 (or perhaps the release before it). It's come and gone on several,
but never really been _fixed_ because nobody seems to quite ever figure
out what causes it. It also was associated with tooltips being triggered
from floaters below the topmost floater.

___
Policies 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] Camera UI in Second Life beta viewer is broken

[Tateru Nino]

The essential bug is that the elements *are* completely covered when
this occurs, but when the mouse-position is matched to an on-screen
element, it ends up matching the wrong thing in the stack. Sometimes.
Under conditions which seem obscure and difficult to reproduce.

And it may match pointing (for tooltips) differently to clicking (for UI
widgets).

On 21/11/2011 8:33 AM, Nexii Malthus wrote:
> That happens because the clicks work by going down a hierarchy, it
> goes down the window backgrounds first, then works through the
> children UI elements of that window, passing around the click message
> until it hits the lowest level.
>
> When you click outside the windows it passes through to the 3D world.
> Even if visually there is a button.
>
> The problem being that the window *must* cover all the child elements
> properly.
>
> - Nexii
>
> On Sun, Nov 20, 2011 at 5:43 AM, Tateru Nino  <mailto:tateru.n...@gmail.com>> wrote:
>
>
>
> On 20/11/2011 2:26 PM, Laurent Bechir wrote:
>>
>> I did the refresh. The problem is not there. The problem is that
>> when I click on a button (Save, Cancel, or another) the viewer
>> react like if I was clicking behind it. For example, if the
>> background of the picture window is the ground, clicking on a
>> button is going to make move my avatar instead of the action the
>> button is supposed to do. The is a turnaround for such buttons as
>> Save to my inventory which consist on clicking on the part which
>> is above the sidebar. But since Save and Cancel buttons are not
>> above this part, they are unusable. I hope I'm more clear :)
>>
> Ahhh, I've seen this problem before! On a number of occasions, in
> fact.
>
> It first started manifesting in the UI code in ... I think it was
> viewer 1.9 (or perhaps the release before it). It's come and gone
> on several, but never really been _fixed_ because nobody seems to
> quite ever figure out what causes it. It also was associated with
> tooltips being triggered from floaters below the topmost floater.
>
>
> ___
> Policies 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] Inventory Patch you should integrate

[Tateru Nino]

On 10/02/2012 6:14 AM, Henri Beauchamp wrote:
> On Thu, 09 Feb 2012 14:11:30 -0500, Oz Linden (Scott Lawrence) wrote:
>
>> Henri, that protocol is not subject to change at this very late date.
> LOL !... You are kidding me, right ?... What's the use to ask for
> feedback if everything is already settled ?... That got to be a
> (very bad) joke !!!
A small correction: The Lab never asked for feedback, as far as I can
tell. What was said was (essentially), "We're changing these things,
here's what can go wrong, this is the patch you should apply."

I don't recall anyone asking for feedback.

___
Policies 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] Inventory Patch you should integrate

[Tateru Nino]

On 11/02/2012 3:26 AM, Henri Beauchamp wrote:
> On Sat, 11 Feb 2012 01:29:43 +1100, Tateru Nino wrote:
>
>> On 10/02/2012 6:14 AM, Henri Beauchamp wrote:
>>> On Thu, 09 Feb 2012 14:11:30 -0500, Oz Linden (Scott Lawrence) wrote:
>>>
>>>> Henri, that protocol is not subject to change at this very late date.
>>> LOL !... You are kidding me, right ?... What's the use to ask for
>>> feedback if everything is already settled ?... That got to be a
>>> (very bad) joke !!!
>> A small correction: The Lab never asked for feedback, as far as I can
>> tell. What was said was (essentially), "We're changing these things,
>> here's what can go wrong, this is the patch you should apply."
>>
>> I don't recall anyone asking for feedback.
> Excepted that the patch is incomplete/non-functional and that
> feedback *is* requested on the Wiki page for Aditi inventory
> test region...
> See: https://wiki.secondlife.com/wiki/InventoryBetaTest#Details
>
> Henri.
Only insofar as to whether it functions or fails to function for the
test criteria, as far as I can see.

___
Policies 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] Pathfinding alpha announced

[Tateru Nino]

There are always future developments. :)

I thought it was clear that we were talking about objects. The 'C' in
NPC doesn't imply that you're talking about an agent or an object in SL
terms, anyway - in many UGC-based virtual environments, NPCs are
*usually* objects rather than agents, though.

I imagined it was kind of clear that the project was about objects, and
not agents.

On 19/02/2012 12:24 AM, Garmin Kawaguichi wrote:
> In the blog post we find the acronym NPC 
> http://en.wikipedia.org/wiki/Non-player_character
>
> I'd prefer here NPO, non playable object 8); in the video I expected to see 
> clones of Lorca Linden !!
>
> Is there going to be future developments?
>
> GCI
>
> - Original Message - 
> From: "Jonathan Welch" 
> Sent: Friday, February 17, 2012 6:23 PM
> Subject: [opensource-dev] Pathfinding alpha announced
>  In case you did not see the announcement yesterday here it is:
>  
> http://community.secondlife.com/t5/Featured-News/Take-a-Sneak-Peek-at-the-Pathfinding-Experiments-Being-Conducted/ba-p/1386511
> ___
> Policies 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] Viewer Policy Changes: Clarity vs. giving clarifications

[Tateru Nino]

Unless the staff member states specifically that it is an official
statement on behalf of the company, yes. It's just hearsay without that
or without an announcement through proper channels.

On 27/02/2012 11:46 AM, Tigro Spottystripes wrote:
> Hasn't LL said in the past that statements by employees should not be
> interpreted as representing the opinions of LL itself, specially when
> it comes to policies and rules and such?
>
> On Sun, Feb 26, 2012 at 12:42 PM, Boroondas Gupte
> mailto:slli...@boroon.dasgupta.ch>> wrote:
>
> On 02/26/2012 02:08 PM, John Jackson wrote:
> > It's just another LL intentionally fuzzy policy.
> > This allows them to make whatever ruling they like when the time
> comes and
> > claim it has been stated "Policy".
> >
> > You will not get any real clarification.
>
> At an inworld meeting, Oz has given the third party viewer
> developers some clarification. Though, I'd prefer policies to be
> written such that they are clear in and of themselves. This
> doesn't mean they cannot let some room for interpretation, but a
> policy shouldn't give a reader with common sense but not knowing
> about the clarifications an impression that clearly contradicts
> the actual intention of the policy.
>
> @Oz: If the policy isn't being changed to be more clear, it might
> be advantageous to re-state the clarifications you gave us at that
> meeting (maybe summarized) here in public, as they are relevant
> for more people than those who were around at the inworld meeting.
>
> Cheers,
> Boroondas
>
> ___
> Policies 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] tired of the bad testting

[Tateru Nino]

Are we talking the viewer's built-in teleportation, or scripted
faux-teleportation (sithacks, etc)?

On 27/03/2012 2:05 PM, Carlo Wood wrote:
> On Mon, 26 Mar 2012 12:15:20 -0400
> "Oz Linden (Scott Lawrence)"  wrote:
>
>> On 2012-03-25 23:56 , Flats Fixed wrote:
>>  the latest stable came out. it broke the teleporters at 2100 meters.
>> you know guys this is not a jira this is simple testing.  love the
>> new policy but the fact is the team is running people out of SL. test
>> it befor it goes stable.
>>
>> Perhaps you could provide a clear problem report?
>>
>> What software were you using?
> The latest stable.
>
>> What did you do?
> Try to teleport back after teleporting to 2100 meter.
>
>> What did you expect to happen?
> The same as with the older viewers.
>
>> What actually happened?
> It didn't work.
> ___
> Policies 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] Tutorial needed on TPV viewer-side AOs

[Tateru Nino]

On 13/04/2012 12:32 AM, Oz Linden (Scott Lawrence) wrote:
> On 2012-04-10 19:01 , Henri Beauchamp wrote:
>> On Tue, 10 Apr 2012 09:01:24 -0400, Oz Linden (Scott Lawrence) wrote:
>>
>>> I'd like to get a tutorial on how the AOs built into viewers work - what 
>>> inputs do they use, and how do they set the animations they set.
>>>
>>> Would someone who's got deep know-how on this either write up one for me 
>>> (or point me to one if it exists), or make some time to go over it with 
>>> me interactively?
>> It would be better implementing a server-side AO (with the viewer only
>> transmitting the replacement animation UUIDs to the server, for example
>> via a capability), because the current viewer-side AOs simply duplicate
>> what scripted AOs are doing (so they are not really better regarding
>> animations priority conflicts, etc) but lack the capability offered by
>> (good) scripted AOs to be auto-switched on and off via the Lockmeister
>> "booton"/"bootoff" commands which allow for cooperation between AOs and
>> with device you sit onto and that want to play their own anim instead of
>> the AO's.
>>
>> I really hope a proper server side AO feature is to be implemented...
>>
>
> The point of my question was twofold:
>
>   * To understand what existing in-viewer AOs were doing so as to
> understand any possible compatibility issues
>   * To discover use cases and what problems in-viewer AOs were created
> to solve
>
>
For the second part:

  * Walking like a duck. The classic issue.
  * Being able to override one or more animations without putting undue
load on a sim (some of those AOs can be really burdensome)
  * Being able to switch between entire sets of animations quickly and
easily. I know people with many complete animation sets that they
switch in and out.

That help some?
___
Policies 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] Tutorial needed on TPV viewer-side AOs

[Tateru Nino]

On 13/04/2012 11:30 AM, Argent Stonecutter wrote:
> The overhead of a conservative scripted AO is pretty low, and the ability to 
> switch AOs by wearing an asset (attaching the AO HUD) means that I can have 
> appropriate AOs for each of my avatars and outfits without having to tweak my 
> client settings each time I jump from kangaroo to grasshopper to dolphin to 
> ferret...
Absolutely - if we were talking client or server-side AOs, they'd have
to be linked to outfits or wearables somehow to maintain parity with
common use-cases.
___
Policies 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] Tutorial needed on TPV viewer-side AOs

[Tateru Nino]

I think it would make more sense than overloading an existing item type
- but that's a server-side mechanics issue.

The important thing would seem to be how to keep the current existant AO
user-experience at the viewer. But that would (yes) have to be kept in
lockstep with the grid side of the equation. So, there's undoubtedly
some protocol work involved too, perhaps an additional message type.

On 13/04/2012 3:09 PM, Adeon Writer wrote:
> Wouldn't a new inventory item type make most sense? That way it could be put 
> in with any outfit folder or packaged with sold avatars.
>
> On Apr 12, 2012, at 10:42 PM, Tateru Nino  wrote:
>
>>
>> On 13/04/2012 11:30 AM, Argent Stonecutter wrote:
>>> The overhead of a conservative scripted AO is pretty low, and the ability 
>>> to switch AOs by wearing an asset (attaching the AO HUD) means that I can 
>>> have appropriate AOs for each of my avatars and outfits without having to 
>>> tweak my client settings each time I jump from kangaroo to grasshopper to 
>>> dolphin to ferret...
>> Absolutely - if we were talking client or server-side AOs, they'd have
>> to be linked to outfits or wearables somehow to maintain parity with
>> common use-cases.
>> ___
>> Policies 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] Tutorial needed on TPV viewer-side AOs

[Tateru Nino]

On 13/04/2012 11:29 PM, Robert Martin wrote:
> The only real thing that HUD AOs have that a client side AO can do is
> the various "buttons" for different things. I normally (back when i
> was inworld) used a Dire Wolf
> this has a bunch of different functions (different animations and
> recoloring things) also will we ever get a way to do a true Quad frame
> (with Mesh Avatars would be good)? since that i think would drop a
> couple scripts from the AO.
>
> My opinion is that looking at what all is done in AOs and then seeing
> if it can be done server side/or in viewer would be a good idea.
Certainly. The current viewer-side AOs are actually incomplete because
of the lack of access to modify grid and protocol code. Studying the use
of actual in-world AOs would yield more and better information than
studying the current viewer-side AOs.

___
Policies 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] Tutorial needed on TPV viewer-side AOs

[Tateru Nino]

On 14/04/2012 3:09 AM, Jamey Fletcher wrote:
> Cinder Roxley wrote:
>
>> An advantage to scripted AO's as has already been stated is that
>> bundling the config, AO, and animations into one object that can be worn
>> and added to specific Outfits is simpiler and conserves Inventory count.
>> AFAIK, any client-side AO relies on animations being unpacked and in the
>> user's inventory, sometimes creating additional object links. AFAIK, the
>> only client-side AO implientation that doesn't do that relied on an
>> external xml config saved to hard disk and was abused by users plugging
>> UUID's of animations in which they did not own. It was subsequently
>> replaced with another implementation.
> One of my friends has different AOs for different outfits - she goes to great 
> trouble to select animations so that while sitting in a skirt, the hands 
> don't 
> go through the skirt during the animation, and similar issues.  I'm not 
> certain 
> just how many AO sets she has, but it's significant.
A dozen sets certainly isn't an unusual number, in my experience - and
many people might have quite a few more than that.

___
Policies 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] Tutorial needed on TPV viewer-side AOs

[Tateru Nino]

On 14/04/2012 11:09 AM, glen wrote:
>
>> I don't really have any insights into the client vs. server vs.
>> scripted AO debate. I think adding asynchronous events would be a very
>> good short-to-medium-term solution, and any scripted AO that used them
>> would probably cause low enough sim load that the whole question could
>> be punted for a long time. Assuming script load is the reason this is
>> being considered.
>>
> I think we've all gone a bit OT to be honest. All he wanted in the first
> place was a quick tut on how the existing in-client AOs worked. I'd
> assume he's considering adding one to the LL client. I agree with Anne
> that he should probably start with the inworld scripted AOs and then
> work from there as there are a lot of possibilities.
That's because the AOs in TPVs are necessarily incomplete - because they
cannot integrate with the server-side. If Linden Lab *were* considering
just dropping similar functionality into the viewer without additional
server-side integration, I'd consider that to only be half a job.

ie: If Linden Lab basically copied what the TPVs do for the official
viewer then creators would once again likely wind up in the position of
telling customers "No, you can't use the builtin thingy. You have to use
the scripted thingy instead, or it won't work properly. Why? Well, it's
kind of complicated to explain..." That's a point of friction that users
don't need.

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

Re: [opensource-dev] New HTTP Library & Project Viewer

[Tateru Nino]

On 31/07/2012 5:28 AM, Monty Brandenberg wrote:
> On 7/30/2012 2:15 PM, Celierra Darling wrote:
>
>> FYI, the Firefox folks had a conversation in 2008 and decided to bump up
>> from 2 to 6 by default at that time (partly because everyone else was
>> raising it).[1]  (And for what it's worth, I found a mention from '06
>> that "anything above 10 is excessive".[2])  That doesn't necessarily
>> mean SL viewers should use the same values, but I think it probably
>> demonstrates where people might try to push that setting, at least at first.
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=423377#c4
>> [2]
>> http://kb.mozillazine.org/index.php?title=Network.http.max-persistent-connections-per-server&diff=28784&oldid=28783
> On the limiting side of things, we have to deal with this
> unfortunately:
>
> http://www.smallnetbuilder.com/wireless/wireless-reviews/26843-linksyswrt54gv5reallyisalousyrouter?showall=&start=4
>
> Finding a one-size-fits-all solution is a challenge when the consumer
> space performance range spans a 3000:1 ratio.
>
> I also did some tests on throughput-vs-concurrency and at 10
> connections we're falling away from linear speedup.  The example
> code in the new library happens to be a performance test framework
> should anyone want to play...
>
It seems almost everyone I know has a linksys WRT. Heck *I* have one,
myself - the rev 2 - and there's three of us feeding through that. (Many
of the non US models have their firmware in ROM, rather than in flash
and can't be updated with DD-WRT). Heck, I know one person with two. A
Belkin G *and* a Linksys WRT.

Rubbish consumer routers are hard to ignore, even if you've got a good
one yourself.

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

Re: [opensource-dev] New HTTP Library & Project Viewer

[Tateru Nino]

On 31/07/2012 3:20 AM, Oz Linden (Scott Lawrence) wrote:
> On 2012-07-29 13:58 , Sheet Spotter wrote:
>> Does increasing the HTTP connection limit also increase the burden on the
>> server and network?
>>
>> Increasing the HTTP connection limit on one client might improve the
>> experience for one person. It might also diminish the experience for
>> everyone else on the same server.
> Exactly so.  The effect is more complex than just consuming file 
> descriptors on the server side, as well.  TCP congestion control works 
> far better when dealing with a smaller number of connections. Any 
> packets that are not subject to congestion control that are sharing the 
> same network path as a TCP connection increase the likelihood of a 
> dropped packet in the connection flow, which causes the connection to 
> immediately cut its transmission window by half. The viewer already puts 
> a lot of UDP traffic into the same path. The handshake packets that open 
> and close TCP connections are also not subject to the congestion control 
> - which means that opening each new connection increases the chances 
> that each of your existing connections will slow down by half.  Opening 
> many connections also puts additional strain on routers in the path that 
> are doing connection tracking (which too many do), adding another 
> possible source of problems.
>
> In general, when persistent connections and pipelined requests (having 
> more than one request in flight on a connection at a time) are used, 
> HTTP performs far better with a small number of connections than with 
> more.  As we begin deploying support for this way of using it on the 
> server side, we'll be able to do good experiments to determine what the 
> right tradeoffs are for network behavior and server load to provide 
> optimal experience for users.
>
>
Also, a badly behaving connection (eg: one that is dropping packets)
leaves the connection open longer, while delivering less data per unit
time. That's basically a *waste* of server resources. If I overload my
crappy consumer router with connections it can't properly handle, I'm
indirectly impacting the experience of other users. Not a desirable
situation.

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

Re: [opensource-dev] New HTTP Library & Project Viewer

[Tateru Nino]

On 31/07/2012 9:13 AM, Henri Beauchamp wrote:
> On Mon, 30 Jul 2012 13:08:18 -0400, Oz Linden (Scott Lawrence) wrote:
>
>> HTTP itself recommends that clients not maintain more than 2 connections 
>> to the same service [1].  I don't know exactly what limit we will decide 
>> is reasonable (I expect that 2 will be ok, but don't know whether or not 
>> some larger number will be also).
> I bet 2 persistent connections will not be as performant as 16 (or even
> only 8) transient ones... Especially for oversea users, when links go
> through a load of routers before the viewer can actually communicate with
> LL's servers (and I have seen numerous times buggy/badly configured routers
> dropping "persistent" connections).

The pipelining of requests *should* contribute a great deal to
per-connection performance - there are outliers where that won't happen
(stuck/stalled connections, broken connections, and so forth), but in
the main properly-implemented pipelining, smartly managed by the viewer,
should provide quite a boost under the most common use-cases, IMO.
> Not to mention the underusage of the additional CPU cores for image decode
> and caching threads (that will have to wait each time and will, at best,
> process 2 images before the next 'bunch' (if 2 is already a 'bunch')
> arrives).
I'm not sure that's actually much of a concern. The number of textures
actually *ready* for decoding at any tick of the clock when they can be
scheduled is generally quite small (just one or two), even under the old
UDP system - more cores for texture decoding tasks primarily benefit the
slower systems where the decoding starts to eat up significant chunks of
user-scale time - or if you're really sucking down oodles of data at
speeds many of us overseas users can't actually pull. (I think it is
generally safe to assume a median data transfer rate of 400Kbps - this
is everyone's cue to jump up and tell me that the number is vastly
over/under any sane view of reality)

So, confining the number of persistent connections to an arbitrary X
(say 2 or 3) doesn't *seem* to me like it would make that much of a
difference in practical terms to many users. It will to *some*,
absolutely, who could doubtless get a *heap* more performance from X+1
or X+2 pipelines. There will always be those cases, IMO.


___
Policies 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] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL

[Tateru Nino]

On 17/02/2013 1:41 PM, Niran wrote:
> Ah good thing i really dont care about this. I mean , Martin is right
> , with adding your stuff you are basically preventing it from getting
> implemented but i have to say its LLs own fault because they insist on
> this damn CA , really , isnt this OpenSource? doesnt OpenSource mean
> that basically everyone can openly help with it?

Not exactly. Open source means that the source is freely available, and
that (subject to certain conditions) can be used in ways which copyright
would normally prevent (each open source license specifies the
conditions under which the three basic rights of copyright might be
relaxed, depending on the license).

Not all open source projects accept all contributions made for it. It's
common for some to be accepted and some to be rejected - depending on
the organisational model.

> i mean why does LL insist on this CA? just so they can say at any
> given time "this code is ours"?.
I cannot speak for the Lab, but I can't envision any other scenario for
CAs under most open source project licenses, than allowing for the
possibility of a future sale of the code as an unencumbered asset. Now,
the presence of the CA system doesn't imply one way or another that the
Lab intends to do that at any future point (though I believe it has been
done once in the past already) - it's something that lawyers like,
though. A lot.
> Seriously this is unnecessary additional work and trouble. I mean
> imagine the worst case scenario where Henri fixes ALL issues SL ever
> had , LL couldnt implement those fixes and basically making them
> unable to ever fix them , because the fixes come from Henri , so
> everyone would either have to create a whole new fix that does exactly
> the same but is build completely different or they dont do anything
> about it at all because there is no other way to fix it (which i
> highly doubt in most cases) , but you get the idea , LL is basically
> limited and crippling itself by denying everything from everyone who
> has no CA.
That's certainly one way of looking at it - and actually this was done
for a while. Fixes were essentially completely reimplemented for the
viewer from the ground up with the original contributed work used only
to generate time/cost estimates, and perhaps specifications.

Yes, I do rather think that the Lab is sort of painting itself into a
corner with this, but under the current organisational model for the
project, it isn't something anyone else has control over. It's a
love-it-or-leave-it sort of situation. Annoying, perhaps, for the bulk
of informed SL users, but not really anything to raise actual ire about.
>
> 2013/2/17 Martin Fürholz mailto:fuerh...@gmx.net>>
>
> Hello again, Henri,
>
> I just tested your nipples and they work without issues in a
> viewer with my
> fix. But they also do work in the official latest LL viewer
> release (Second
> Life 3.4.5 (270263) Feb 12 2013 04:43:00 (Second Life Release)).
>
> Martin RJ
>
> -Ursprüngliche Nachricht-
> From: Henri Beauchamp
> Sent: Sunday, February 17, 2013 12:58 AM
> To: opensource-dev@lists.secondlife.com
> 
> Cc: MartinRJ Fayray
> Subject: Re: [opensource-dev] Review Request: BUG-840: Viewer
> 3.4.2 (Beta)
> breaks almost every sliding door script in SL
>
> On Sat, 16 Feb 2013 19:44:51 -, MartinRJ Fayray wrote:
>
> > This is an automatically generated e-mail. To reply, visit:
> > http://codereview.secondlife.com/r/616/
> >
> > Review request for Viewer.
>
> Yes, it seems to work more or less OK. It however still fails to
> animate
> visible small resizing primitives (I saw this first on scripted
> nipples:
> the nipples failed to "stiffen" on screen while the prim actually
> resized and only a change in LOD (zoom-out followed with zoom-in)
> would
> update the prim size on screen).
>
> To reproduce that bug, create two prims, link them, and in the
> root prim
> put this script:
>
> integer Expanded = FALSE;
>
> default {
> touch_start(integer n) {
> vector scale = llList2Vector(llGetLinkPrimitiveParams(2, [
> PRIM_SIZE ]), 0);
> Expanded = !Expanded;
> if (Expanded) {
> scale.x = 2.0 * scale.y;
> } else {
> scale.x = scale.y;
> }
> llSetLinkPrimitiveParamsFast(2, [ PRIM_SIZE, scale ]);
> }
> }
>
> Then wear the resulting object and resize it down to a very small
> size.
> Zoom on it and see how the child prim fails to resize when
> touching the
> object.
>
> To cure that bug you need to replace:
>
> LLVector3 vec = mCurrentScale-target_scale;
> if (vec*vec > MIN_INTERPOLATE_DISTANCE_SQUARED)
>
> (which makes no sense whatsoever: only damping interpolations need to
> be checked against MIN_INTER

Re: [opensource-dev] Replacement class for LLDynamicArray

[Tateru Nino]

On 10/05/2014 2:35 AM, Brian McGroarty wrote:
> On Fri, May 9, 2014 at 8:43 AM, Nicky D.  > wrote:
>
> True, but on the other hand, you'd never call array[i] with i
> out of
> array bound (it would be a bug, and throwing an exception via
> the use
> of at(i) is no better than "undefined behaviour"
>
> that will also lead to a crash in the end).
>
>
> Wrong. See Heartbleed.
>
>
> Slight tangent, but I love these kinds of shares:
>
> http://article.gmane.org/gmane.os.openbsd.misc/211963
> http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf
> http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
>
> tl;dr: Heartbleed persisted for so long because even though checking
> existed, the OpenSSL engineers built their own heap management that
> sat on top of anything provided by the OS and compiler vendors'
> libraries. Then, nobody created a unit test or other check that
> validated behavior without their heap management in place. It should
> be The Least-Surprising Thing Ever that the library then became
> uncompileable without the less secure heap manager.
>
> I don't see an argument for an expensive extra check in production
> builds in either HeartBleed or our own use of vectors. Rather, making
> sure the case is covered in unit tests and/or debug builds could save
> the day.
>
Totally agree. There's no need (or desirability) to check constantly in
production code, if you can achieve the same results with proper
testing. Solid foundations don't /guarantee /a solid structure, but
shaky foundations /always /undermine any structure you try put on top of it.

The important thing is to make sure that constant bounds-checking in
production code is never /necessary/.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Tateru Nino]

When I think of client-side scripting for the viewer, I'm definitely
thinking of the latter, not the former. Inworld objects sending limited
scripted tasks to the viewer? Doesn't even seem all that useful or
desirable, though surely there must be *some* use-cases.

On the other hand, being able to plug scripts of my own (or others')
devising in to the viewer to improve accessibility and customize
usability? Huge win. I've got endless numbers of invoicing and
communication tasks that would benefit from being able to build my own
data-pipelines or just save myself clicks and keystrokes every time around.


On 20/02/2010 10:14 AM, Latif Khalifa wrote:
> People seem to be confusing two different things: client side
> scripting, and client extensions or plugins.
>
> 1. Client side scripting
>
> Think web browsers. They all support execution of client side scripts
> in one language in sandboxed environment. So the way original post
> describes proposed design for client side scripting fits neatly in
> this scenario.
>
> Having a unified platform that scripts can depend on existing in the
> client (say viewer 2.3 and up support it) would allow all sort of new
> and innovative content to be created.
>
> 2. Plugins
>
> Think Firefox extensions/plugins. Like Flash, Java applets, etc. This
> is entirely different concept. In-world content cannot depend on these
> being present, and have to allow for situation where  some users have
> some plugins installed, while other do not.
>
> Both of these concepts would be a welcome addition to the viewer. I
> would imagine that the needed internal changes to the viewer could be,
> at least partially, used for implementation of both. If the first step
> is to implement client side scripting as described above, we should be
> talking about it, and separate plugin discussion into a different
> thread.
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>
>   

-- 
Tateru Nino
Contributing Editor http://massively.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

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

[Tateru Nino]

Okay, so which one of these is the Lab thinking about, then? That'll
settle a lot of debate right there.

On 20/02/2010 2:00 PM, Argent Stonecutter wrote:
> On 2010-02-19, at 01:16, Ricky wrote:
>
>   
>> I suspect that there are two things being discussed here without  
>> distinction: Client scripting, and client extensions.  Confusing the  
>> two is easy.
>>
>> Client-side scripting SHOULD be sandboxed, and in a controlled set  
>> of languages.  For a close example think of javascript in web  
>> browsers.
>>
>> Client extensions, or alternatively named as "plugins", would be  
>> modules that can be plugged in and out of the client and run /as if/  
>> they were a part of the client.  Think of browser add-ons/plugins/ 
>> extensions.
>>
>> Client side scripts could (read might be, could possibly, needs  
>> further thought, etc.) be given permission to be loaded in by worn  
>> items automatically.  Other objects would likely need to request  
>> permission via a security warning.
>>
>> Client extensions would have to be downloaded and installed  
>> externally; not delivered in-world.  These would truly be programs  
>> on your computer, and should be treated as such.
>>
>> Just my thoughts hoping for a clearer discussion.
>> 
> A very good summary. Thank you.
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>
>   

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Third party viewer policy

[Tateru Nino]

If I was running on the equipment provided by my ISP, rather than
assembling my own kit, I wouldn't have a MAC address either.

On 26/02/2010 4:31 AM, Argent wrote:
> Sorry for not editing this in detail, Opera is SLOW as hell in a
> thread this long in gmail.
>
> I understand why they're asking for a MAC address. I'm pointing out
> that a viewer may be running on a device that HAS NO MAC ADDRESS.
>
> On Wed, Feb 24, 2010 at 8:28 AM, Scott McCulley  <mailto:smccul...@gmail.com>> wrote:
>
> Argent,
>
> >From a network standpoint, the mac address is a layer two address
> that is not seen when crossing a router to a new network. So,
> therer is no way to see your mac address from the network packets.
> LL is using the mac address as a unique identifier of your
> computer. When you use the SL viewer, it can read your mac address
> locally, then send it along to LL to be used to identify you on
> the grid. So if you have multiple accounts that you use from the
> same computer, they know it is you, no matter what your IP
> address, proxy server, or other network layer protection is used.
>
> In the case of known griefers, LL could simply disable access from
> that mac address that is reported by the viewer, and the person
> cannot get back in to the grid, regardless of IP or SL account.
> The only way is to use a completely new computer with a different
> mac address.
>
> That being said, if the developers mask the ability to read and
> report the mac address to the LL grid, they lose the abilit to
> block the bad guys.
>
> -Scott
>
>
> Sent from my iPhone
>
>
> On Feb 24, 2010, at 5:49 AM, Argent Stonecutter
> mailto:secret.arg...@gmail.com>> wrote:
>
> Admittedly this is not likely to be a common scenario, but the
> whole
> idea that a MAC address is a unique identifier for a device is
> based
> on a deep-seated confusion about the network stack.
>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

-- 
Tateru Nino
Contributing Editor http://massively.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

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

[Tateru Nino]

Ah, I'm starting to see now. Developers are only subject to the TPV
policy if they want to be listed in the directory. Users are subject to
the policy should they choose to use a TPV to connect to a
Linden-operated grid, rather than an alternative (like OpenSim)

Makes sense, but that would really mean that the TPV policies should be
a part of the Terms of Service, wouldn't it> Doesn't make much sense to
have them separated.

On 1/03/2010 12:36 PM, Joe Linden wrote:
> TPV developers may choose to list their viewers in the Directory for
> the value of receiving a wider awareness than they may be able to
> create themselves, or not.  That's entirely up to the developer.  All
> viewers that connect to the SL grids will need to abide by the TPV
> Policy regardless of their choice to list in the Directory.
>
> And, since we're only talking about conditions that apply when a TPV
> connects to Linden Lab's grid(s), we reserve the right to add,
> subtract, or otherwise modify those conditions at any point in the future.
>
> -- joe
>
> On Sun, Feb 28, 2010 at 4:44 PM, Morgaine
>  <mailto:morgaine.din...@googlemail.com>> wrote:
>
>
> ... Since it's just promotion, TPV developers are free to ignore
> it when they excel on features and don't need promotion, and of
> course you will never make promotion mandatory.
>
> Morgaine.
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

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

[Tateru Nino]

On 10/03/2010 10:09 AM, Armin Weatherwax wrote:
>   
>> I am simply pointing out that they are NOT compatible with the GPL.
>> 
> GPL compatible or not - the sentence "The Snowglobe Viewer [...] this 
> viewer may be somewhat less stable than the official Second Life 
> viewer"( http://viewerdirectory.secondlife.com/ at 2010/03/10 00:06 
> GMT+1) is a slap into the face of anybody contributing bugfixes to the 
> secondlife codebase.
>   
It might be true at some times and not at others (right now, Snow2 is a
whole lot more stable than V2 beta in my experience), but it reads like
a calculated slur.

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] New topic: Snowglobe 2.0 way forward?

[Tateru Nino]

Building and scripting are generally high-immersion activities (that is,
they work best with plenty of focus and few distractions).

On 11/03/2010 9:41 AM, Martin Spernau wrote:
> Ok, this is my very personal impression from my use:
> * anything that requires me to switch focus will break my immersion
> That is true for having to switch from keyboard to moise (like if I 
> need to CLICK to focus on the IM text entry, instead of being able to 
> use a keyboard shortcut)
>
> In that thought... I'd think that having to switch windows - or even 
> monitors to read the chat/IM or select things in the inv... would 
> break my immersion.
> Note that this does not apply lilewise for activities like scripting 
> or building. These are not so much about immersion, but more about 
> effcient workflow and 'having it all organized' - sp here being able 
> to put the script editor etc on a window outside the world view seems 
> very much a want-to-have
>
> My current concept was this:
> * I was thinking of reducing the clutter of UI widget on the world 
> view by taking the sidebar conceot to it's max... putting all UI (or 
> most) panels into this sidebar. Important here would be a good set of 
> keyboard shortcuts to quickly switch between tabs etc
> That might slo have the added benefir of being able to quickly blend 
> out all UI or bring it back - sliding the sidebar as it does. (ok, you 
> can do that with mouselook)
>
> Anyway, my feeling is that immersion is less a matter of where things 
> are on screen... but how naturally I can access them.
>
> -Martin
>
> Am 10.03.2010 um 23:13 schrieb Tigro Spottystripes:
>
> having GUI elements as completly separated windows from the world
> rendering is much different form squeezing the world view in order to
> show more GUI elements, it's actually kinda like having windows on top
> of the world view, except that you can also move them from out of it.
>
> That approach actually may allow for both styles (over the world view
> and fighting for space with it), while also allowing the third style  
> for
> people with multiple monitors, where the world view uses the whole
> screen space, while communications and other elements are still
> displayed without reducing the visibility of the world at all.
>
>
> I'm not completly sure about how i feel in relation to the immersion  
> of
> the third style, i think i would interpret the external windows as
> additional senses to vision, i think it's a nice mix of all sorts of
> possibilities, it's flexible enough to satisfy all tastes, or at least
> the most common ones.
>
>
>
>
> On 10/3/2010 18:47, Martin Spernau wrote:
> >>> Am 10.03.2010 um 22:35 schrieb Tigro Spottystripes:
> >>>> IMO, windows that are on top of the view like a Heads Up Display  
> >>>> feel
> >>>> more like they're part of the world, like they are in the same place
> >>>> as
> >>>> i am, while a bar that makes the world view smaller makes it feel  
> >>>> like
> >>>> the world view is just a screen showing images on a panel with a  
> >>>> bunch
> >>>> of controls in it.
> >>>
> >>> It's interesting then that many of the alternate metaverse viewers  
> >>> try
> >>> to fully decouple the UI (chat boxes, imventory etc) completly from
> >>> the world view window to the point where they are separate windows
> >>> (while the Sl viewer still has it 'all in one wndow').
> >>> Seen with this view of 'immersion' that seem like not so good an  
> >>> idea...
> >>> Thanks for bringing this up, it got me thinking about a few  
> >>> concepts I
> >>> had.
> >>>
> >>> -Martin
> >>> ___
> >>> Policies 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


-- 
Tateru Nino
Contributing Editor http://massively.com/

-- 
Tateru Nino
http://dwellonit.taterunino.net/


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

Re: [opensource-dev] Proposal: Howto add a new feature to snowglobe.

[Tateru Nino]

 patch may be committed.
>
> Category 2
> --
>
> In the case of a new feature, the new feature should really
> first be discussed on this list, before being implemented.
>
> What is being discussed are the effects on the users, not
> the technical effects like CPU usage etc. Non-committers
> can (politely) provide insight and feedback, but do not
> have any vote on whether or not a new feature will be added.
>
> In fact, nobody has a vote: in the end it's the call of
> Linden Lab, where we assume that if any Linden speaks his/her
> decision on the list that that is the internal decision of
> Linden Lab (and another Linden will not suddenly oppose).
>
> Each feature must be carried by a committer. That is, someone
> must step forward and offer to write it, test it and be
> prepared to through the hassle of Catergory 1 above. In most
> cases this will be a committer whose own idea the feauture
> is, that is the advantage of putting time into actually
> writing (good) patches. It is not a bad thing that committers
> have this priveledge. Of course, it is also possible that
> a committer decides to backup an idea of someone else.
> [There is no reason he cannot be paid for that, but I expect
> that in general this will not be the case].
>
> Linden Lab will take the following into account when making
> their decision about a new feature:
>
> * This is about Snowglobe ONLY; whether or not it's also
>  added to the official viewer is a separate issue.
> * They will NOT take maintainability into account, that
>  is the responsibility of the open source community.
> * If the new feature has no last impact on the user
>  base, which can always be achieved by making it optional
>  and/or not the default, they will let themselves strongly
>  be influenced by the consensus of the list discussion.
> * The opinion of committers is taking more into account
>  than the opinion of non-committers, because it's the
>  committers who have to maintain the code.
> * The decision is made in a timely manner (ie, within
>  two weeks after the discussion on this list dies out).
>  If no decision is communicated within a reasonable
>  time, they right to a final decision forfeits and the
>  feature may be added (all with gentlemen agreement of
>  course).
>
> For example, the Life Cycle of a new feature might be
> the following:
>
> * User thinks of new feature and adds it to the jira.
> * Several people find it and vote for it.
> * Feature comes to the attention of someone on this
>  list and brings it under the attention of a committer.
> * Committer commits himself (haha) and post to the list
>  with implementation detail ideas.
> * Everyone has their say in a civil and polite way.
> * The design (on "paper") goes through a few cycles
>  until the committer that committed himself doesn't
>  want to make more changes.
> * Linden Lab gives the red or green light.
> * In case of a green light, the committer writes a
>  patch and tests it. Then attaches it to the jira.
> * At least one other committer tests it and makes
>  comments about implementation details.
> * Original committer rewrites the patch and/or
>  fixes bugs, until all other committers that want
>  to spend time on reviewing are satidfied.
> * The patch is committed.
>
> --
> 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

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

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

[Tateru Nino]

Color me old-fashioned, but if that is the case, then the policy
agreement shouldn't actually overstep to that software... but it does by
a simple, reasonable reading.

On 22/03/2010 6:19 AM, Joe Linden wrote:
> No, it only governs viewers that actually do connect to the SL grid,
> not those that are capable of doing so (but don't.)
>
> On Sun, Mar 21, 2010 at 11:59 AM, Ryan McDougall  <mailto:sempu...@gmail.com>> wrote:
>
>
> If so, in effect, the TPV policy governs all SL protocols?
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Client 2.0 - sidebar

[Tateru Nino]

Sounds like Virtual Environment Sickness (a perceptual dissonance malady
somewhat akin to seasickness). While it affects about 30% of the
population from the USAF studies that I've seen, I haven't read anything
to suggest that either the SL viewer or LCD monitors affect the overall
prevalence of the condition.

On 24/03/2010 9:55 PM, Argent Stonecutter wrote:
> Not to disagree with the entirety of your rant, but this bit seems  
> completely off the wall.
>
> On 2010-03-23, at 21:39, Jonathan Irvin wrote:
>   
>> Not to be rude, but if people are getting vertigo, epilepsy, etc.  
>> from SL...viewer 2.0 isn't going to make a difference.  Viewer 1.23  
>> would have the same effect.  Maybe not in your coveted sidebar, but  
>> it SL in general.  You know it, I know it, everyone knows it.  This  
>> is common knowledge.
>> 
> It is? I'd never heard of it before. I don't get vertigo from SL. I do  
> get it from some games, like Descent, and I was getting it from the  
> sudden uncontrolled slewing of the viewport in the 2.0 viewer. But not  
> SL.
>
>   
>>   LCD monitors nowadays will cause those effects *regardless* of the  
>> application running, so please don't make someone else's illness as  
>> your point in voicing your opinions.
>> 
> Um, what? Cite please.
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>
>   

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] HTTPRequests region limit.

[Tateru Nino]

llHTTPRequest returns 499 for a whole variety of conditions, actually
including gateway timeouts, some DNS errors, ACL denial, request headers
or request bodies that are larger than the system is willing to handle,
response headers or response bodies that are larger than the system
wants to handle, and more.

If the HTTP status is passed back from the target server, you get it
(except for certain 'unexpected' values, which will automatically cause
the transaction to behave as if it failed) - for every other possible
condition, you seem to get a 499.

On 5/04/2010 2:07 AM, Jor3l Boa wrote:
> Hello there, I need help with llHTTPRequest and a region limit that is
> giving me 499 http_status, I was testing and seems like the region
> stops accepting requests when one or more scripts requests over 230
> pages. None of those objects reached or passed the 25 requests per 20
> seconds limit. Is there a way to confirm this error and know how many
> time the server needs to accept more requests? Thanks and sorry for my
> english
>
> Jor3l Boa
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Another crazy idea... what list for this one?

[Tateru Nino]

Something like FlashVNC?

On 8/04/2010 3:08 PM, Glen Canaday wrote:
> What would the appropriate list for this be? I'm pretty sure it's not 
> this one,
>
> Anyone know of a flash desktop exporter? For two-way web interaction 
> with your own desktop? Killer app for shared media... using your own 
> computer! ;)
>
> I've thought of perhaps a web-based desktop environment to render / 
> export my X display to my web server with which I can then interact and 
> work while logged into SL. Perhaps a buffer program that captures the X 
> drawables and hands them to a flash app for web-based display. Imagine 
> remote server admin possibilities, etc... not having to minimize SL to 
> check job progress; share the desktop as if you were in the same room. 
> Devs could literally be looking at a desktop thousands of miles away 
> like gotomeeting, watching the same compile messages fly by, using the 
> same primary display from inworld without the hassle of the software 
> incompatibilities that gotomeeting and ultravnc have beyond running the 
> exporter itself. Export a second desktop or stretch it across two 
> shared-media prims like dual monitor setups in RL. The virtual workplace 
> redefined. Office in your underwear, 'cept your av is wearing the ugly, 
> ill-fitting business suit your boss likes.
>
> --GC
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>
>   

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Brown-bag meeting to continue dialog on TVPV

[Tateru Nino]

That's the way I read it also. Also, a user's compliance to the TPVP
survives the termination of the agreement (per §11.7), so if you've
already agreed to the new TOS, you're bound by the TPVP (via §7.8) even
if you terminate your agreement before 30 April, so long as you accepted
the new TOS at least once. Funky.

On 9/04/2010 12:32 PM, Boy Lane wrote:
> Thanks Joe.
>
> Unfortunately one can not attend without going inworld and accepting
> ToS/TPV in the first place.
>
>
>   
>> - Original Message - 
>> Date: Thu, 8 Apr 2010 13:24:57 -0700
>> From: Joe Linden 
>> Subject: [opensource-dev] Brown-bag meeting to continue dialog on TVPV
>> next Tuesday (4/13)
>> To: OpenSource-Dev 
>> Message-ID:
>> 
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hello, all.  I've been reading the ongoing commentary here, on various
>> blogs, irc, and in-world groups about the recently introduced Third Party
>> Viewer Policy and Directory and I'd like to host an "office hour" or
>> informal brown bag to make the conversation a little more synchronous for
>> those who are interested.  I plan to hold three of these over the next
>> couple of weeks, at times that might be friendlier for some than others, 
>> but
>> the first one will happen next Tuesday, 4/13 at noon PDT.  I'd like to
>> address questions about the intent of the policy, how we will be using the
>> Directory going forward, and see if I can gather the specific concerns 
>> that
>> have been raised by the community over the past several weeks.  It'll be 
>> an
>> informal Q&A session, held in voice, at this location:
>>
>> http://maps.secondlife.com/secondlife/Linden%20Estate%20Services/229/230/29
>>
>> No RSVP needed, and feel free to rebroadcast the invite to others you 
>> think
>> would benefit from open dialog around the subject.
>>
>> I hope to see many of you there next week.
>>
>> -- 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
>
>   

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Brown-bag meeting to continue dialog on TVPV

[Tateru Nino]

That clear statement is inadmissible by the terms of the TOS §13.3, I'm
afraid, which disclaims such as not being a valid part of the agreement.
No part of the agreement that is made admissible by §13.3 suggests or
implies any commencement date other than immediately.

Nor does it permit any explanation, FAQ, supplement, or discussion to be
considered relevant (except as provided, which none have been).
Boilerplate it may be, but it is binding boilerplate. It could say that
"This agreement grants you a lifetime supply of banana custard", but
that's not actually in there. It would be an assurance that is
disclaimed within the agreement. §10.3 absolves the Lab and its
representatives of charges of fraud if they say something about the
agreements that aren't strictly speaking true, in order to obtain agreement.

As a general rule for contracts and agreements (leaving aside the TPVP,
the TOS, and Linden Lab for a moment), it's widely considered remiss to
act based on inadmissible representations or explanations of a contract
from /the other party to the actual agreement/. That's the sort of thing
lawyers warn you not to do.


On 9/04/2010 3:32 PM, Joe Linden wrote:
> Of course you can.  The ToS presented at login clearly states it
> becomes effective on 4/30.  In the meantime, you continue to use the
> service under the terms of the prior ToS which doesn't contain the TPV
> provisions.  If one has issues with the prior ToS agreement, and
> hasn't previously accepted those terms, then I agree, this meeting
> isn't for you.
>
> -- joe
>
> On Thu, Apr 8, 2010 at 7:32 PM, Boy Lane  <mailto:boy.l...@yahoo.com>> wrote:
>
> Thanks Joe.
>
> Unfortunately one can not attend without going inworld and accepting
> ToS/TPV in the first place.
>
>
> - Original Message - Date: Thu, 8 Apr 2010 13:24:57 -0700
> From: Joe Linden mailto:j...@lindenlab.com>>
> Subject: [opensource-dev] Brown-bag meeting to continue dialog
> on TVPV
> next Tuesday (4/13)
> To: OpenSource-Dev  <mailto:opensource-dev@lists.secondlife.com>>
> Message-ID:
>  <mailto:v2k6b9495c41004081324ibd5ec762zb8d098a09c7f0...@mail.gmail.com>>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello, all.  I've been reading the ongoing commentary here, on
> various
> blogs, irc, and in-world groups about the recently introduced
> Third Party
> Viewer Policy and Directory and I'd like to host an "office
> hour" or
> informal brown bag to make the conversation a little more
> synchronous for
> those who are interested.  I plan to hold three of these over
> the next
> couple of weeks, at times that might be friendlier for some
> than others, but
> the first one will happen next Tuesday, 4/13 at noon PDT.  I'd
> like to
> address questions about the intent of the policy, how we will
> be using the
> Directory going forward, and see if I can gather the specific
> concerns that
> have been raised by the community over the past several weeks.
>  It'll be an
> informal Q&A session, held in voice, at this location:
>
> 
> http://maps.secondlife.com/secondlife/Linden%20Estate%20Services/229/230/29
>
> No RSVP needed, and feel free to rebroadcast the invite to
> others you think
> would benefit from open dialog around the subject.
>
> I hope to see many of you there next week.
>
> -- 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

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Brown-bag meeting to continue dialog on TVPV

[Tateru Nino]

My apologies, Joe - I'll email you directly.

On 10/04/2010 1:28 AM, Joe Miller wrote:
> Tateru,
>
> You can continue down this road if you wish, but the facts are the
> words in 13.3 do not become effective for Residents who had registered
> before March 31, 2010 until April 30 2010.  (See the blog post here
> <https://blogs.secondlife.com/community/community/blog/2010/03/31/updated-second-life-terms-of-service>
> with additional words to that effect.)  The updated TOS text was
> pushed to everyone so they would have the benefit of a full 30 days to
> review it before acknowledging formal acceptance of it by accessing
> the system after April 30. 
>
> So, please, do not add to the rhetoric here by telling me about
> contract law, charges of fraud, coercion or whatever point you're
> trying to make.  The TOS in force today was the agreement accepted by
> all Residents of record prior to March 31.  After April 30, everything
> you say about section 13.3 in the new TOS is reasonably accurate.
>
> The purpose of my brown bag is to talk about the new TPV policy and
> the concerns raised by several members of the open source community. 
> I intend to listen to listen to all reasonable proposals to address
> those concerns.  Those who do not wish to participate in that
> synchronous event can email me instead if they so choose.   Again, I'm
> looking forward to a productive exchange of specific ideas to address
> specific shared concerns, whether at these meetings or via some other
> channel.
>
> If you have nothing to offer, there is no reason to come.
>
> -- Joe
>
>
> Tateru Nino wrote:
>> That clear statement is inadmissible by the terms of the TOS §13.3,
>> I'm afraid, which disclaims such as not being a valid part of the
>> agreement. No part of the agreement that is made admissible by §13.3
>> suggests or implies any commencement date other than immediately.
>>
>> Nor does it permit any explanation, FAQ, supplement, or discussion to
>> be considered relevant (except as provided, which none have been).
>> Boilerplate it may be, but it is binding boilerplate. It could say
>> that "This agreement grants you a lifetime supply of banana custard",
>> but that's not actually in there. It would be an assurance that is
>> disclaimed within the agreement. §10.3 absolves the Lab and its
>> representatives of charges of fraud if they say something about the
>> agreements that aren't strictly speaking true, in order to obtain
>> agreement.
>>
>> As a general rule for contracts and agreements (leaving aside the
>> TPVP, the TOS, and Linden Lab for a moment), it's widely considered
>> remiss to act based on inadmissible representations or explanations
>> of a contract from /the other party to the actual agreement/. That's
>> the sort of thing lawyers warn you not to do.
>>
>>
>> On 9/04/2010 3:32 PM, Joe Linden wrote:
>>> Of course you can.  The ToS presented at login clearly states it
>>> becomes effective on 4/30.  In the meantime, you continue to use the
>>> service under the terms of the prior ToS which doesn't contain the
>>> TPV provisions.  If one has issues with the prior ToS agreement, and
>>> hasn't previously accepted those terms, then I agree, this meeting
>>> isn't for you.
>>>
>>> -- joe
>>>
>>> On Thu, Apr 8, 2010 at 7:32 PM, Boy Lane >> <mailto:boy.l...@yahoo.com>> wrote:
>>>
>>> Thanks Joe.
>>>
>>> Unfortunately one can not attend without going inworld and accepting
>>> ToS/TPV in the first place.
>>>
>>>
>>> - Original Message - Date: Thu, 8 Apr 2010 13:24:57
>>> -0700
>>> From: Joe Linden mailto:j...@lindenlab.com>>
>>> Subject: [opensource-dev] Brown-bag meeting to continue
>>> dialog on TVPV
>>> next Tuesday (4/13)
>>> To: OpenSource-Dev >> <mailto:opensource-dev@lists.secondlife.com>>
>>> Message-ID:
>>> >> 
>>> <mailto:v2k6b9495c41004081324ibd5ec762zb8d098a09c7f0...@mail.gmail.com>>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Hello, all.  I've been reading the ongoing commentary here,
>>> on various
>>> blogs, irc, and in-world groups about the recently
>>> introduced Third Party
>>> Viewer Policy and Directory and I'd like to host an "office
>>

Re: [opensource-dev] Stuff from my Lunch Bag

[Tateru Nino]

 (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

-- 
Tateru Nino
Contributing Editor http://massively.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

Re: [opensource-dev] opensource-dev Digest, Vol 3, Issue 40

[Tateru Nino]

Curious. How many of us got professional legal advice? I did. I know a
couple of you that did likewise. I'd be interested in knowing how many
others. (There'd be no need to clutter things with negative answers -
and it might be more appropriate to reply offlist - since the question
is a work-related one for me).

On 10/04/2010 11:45 PM, Carlo Wood wrote:
> You know, this would actually make me feel better if you were a lawyer.
> Even more so, if you were a Linden Lab lawyer. But since (I assume) neither
> is the case, this is just your interpretation and I see it differently.
>
> On Sat, Apr 10, 2010 at 04:19:00AM +0200, Dirk Moerenhout wrote:
>   
>>> If the first one was re-written to say "you are responsible for all NEW
>>> features etc that you ADDED to make a Third-Party Viewer, etc" it would
>>> be more clear.
>>>   
>> That will create a false sense of safety. When LL removes code from
>> the source tree for legal reasons you'd make a TPV developer believe
>> that he's not liable for that code if he keeps on distributing it (as
>> you just made him believe he's only responsible for what
>> developed/added himself). Yet when he has been informed that the code
>> can not be legally distributed willful continued distribution is an
>> issue and may see him ending up in court. Off course he should know
>> this if he reads and understands the GPL. The GPL clearly demonstrates
>> responsibility for distribution in section 7.
>>
>> 
>>> The second one should simply drop "develop or distribute".  The GNU GPL
>>> license on LL own page states "6. ...You may not impose any further
>>> restrictions on the recipients' exercise of the rights granted herein."
>>> (in this case, "you" being Linden Research), and further includes the No
>>> Warranty
>>> paragraphs 11 and 12.  Therefore any attempt to impose responsibility,
>>> risks, expenses, etc on a developer appear to conflict with the GPL.
>>>   
>> No it should not. For starters you do not quote it in full. It
>> actually says "You assume all risks, expenses, and defects of any
>> Third-Party Viewers that you use, develop, or distribute. Linden Lab
>> shall not be responsible or liable for any Third-Party Viewers."
>> Punctuation is used for readability but doesn't remove the second
>> sentence from the context. This is LL waving responsibility more than
>> it is about who it transfers to. If you consider section 11 and 12 of
>> the GPL this is a reiteration of "THE ENTIRE RISK AS TO THE QUALITY
>> AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE
>> DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
>> CORRECTION.". Note that LL did not restrict you from passing the risks
>> on to the users of your TPV (they actually imply it transfers to them
>> already).
>>
>> Granted. In the TPVP, like most similar legal documents, they have
>> reiterated quite a few points that are covered already for example by
>> the GPL or the TOS. But as I stated before I still need to see the
>> first sensible example of how this affects somebody beyond what they
>> should expect regardless of the TPVP.
>>
>> Dirk
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting 
>> privileges
>> 
>   

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Stuff from my Lunch Bag

[Tateru Nino]

On 11/04/2010 1:06 AM, Gareth Nelson wrote:
>> Not that the Lab actually needs anything resembling the TPVP to successfully
>> take legal action against someone making pernicious viewers available or
>> creating them for their own use.
>> 
> I can use telnet to break into various TCP-based servers, does that
> make the authors of my telnet client liable for my actions?
>
> I can also (and have done so as part of a few penetration tests) use
> the metasploit framework to break into various machines - are the
> authors of metasploit liable for my actions?
>
>
> Unless there's some precedent to the contrary, it would seem that the
> user remains liable and not the developer of the tools
>   
It's a matter of intent. Some things are not actionable unless there was
intent to cause loss or damage. Intent's something you need to prove in
a court. Obviously, the developers of telnet clients - as a rule - do
not intend for them to cause harm.

The law revolves around the punishment of those who make /choices /that
lead to damage, but that gets a bit hazy. Certain kinds of negligence
can be considered a choice, and so on. Tort law is rich and baroque.

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] impending lawsuit?

[Tateru Nino]

I'm aware of the speed-rez stuff, because it's been discussed numerous
times over the last five years. The earliest mention I can recall off
the top of my head is a suggestion from Phoenix back in early 06.

I've already read the complaint and docs and I'm working on an article
on it.

On 14/04/2010 6:28 PM, Lance Corrimal wrote:
> Hey all,
>
> just got this notecard inworld:
>
> "Hello.
>
> You are reading this because you were listed in a lawsuit by Belial Foulsbane 
> and Scarlett Vielle.   
> Somehow you are a victim of his False DMCA claims, and his ongoing effort to 
> manipulate LL into killing off his competition for the "Emerald Speed Rez".
>
> If you would like to join the defendants against this paperwork-greifer in a 
> counter lawsuit please contact me with your SL name and anything else at 
> prime...@gmail.com
>
> Do not be scared
> 1)  Scarlett Vielle claimed that they automaticly had a protected copyright 
> from the moment they made anything.
> (The US copyright office is not aware of every creation in SL, does not issue 
> free copyrights, and does not issue anything without a proper filing)
>
> 2)  There is no copyright registered in the united states:
> http://cocatalog.loc.gov/cgi-bin/Pwebrecon.cgi?DB=local&PAGE=First
>
> 3)  Linden Labs cannot be sued.  Yet he filed against them.
>
> 4) The judges signature on his legal papers he faxed to LL is blank.
>
> 5)  He cannot copyright the word "Emerald" for the same reason he cannot 
> copyright the word "SecondLife" or "Microsoft".
>
> He is a paperwork bully filing false DMCA claims as you know.
>
> If you have any ideas to stop this madman, do please share them.
> Lets create a group and fight him off shall we?
>
> zFire"
>
>
> ... is that guy out of his mind?
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>
>   

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

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

[Tateru Nino]

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

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Requesting Linden Response: Please move TPVP Topics to a different mailing list

[Tateru Nino]

It isn't just the messages that need to scale. Messaging is probably the
bottom of the list of use-cases for groups in practice. It's the bit
where most of the actual *problems* show up, but it isn't actually as
important a part of group scaling as the rest of the group functions.

On 17/04/2010 11:27 PM, Carlo Wood wrote:
> Scaling of group messages is simple however.
> With one server per group you get a long way.
>
> Lets say, 2000 connections per server on average.
> Usually about 1/10th of the users is online, so
> you can keep adding groups to a server until
> the total number of group members is around 20,000.
> Then you add a server.
>
> The routing to the servers can be done by using the DNS
> system, for example .groups.secondlife.com
>
> And if you throw a good socket library against it
> (not one using select or poll), you can add to 20,000
> users per server; that still won't be a problem CPU-wise.
> Unfortunately some kernel tweaking and expertise is needed
> in that case, but just hire some IRC admin of a large server
> and they can tell you how to do that.
>
> On Fri, Apr 16, 2010 at 06:20:21PM +0200, Dale Glass wrote:
>   
>> IIRC, the main issue with the group limit and IM is scaling. There can be 70K
>> people online. Suppose you bump the groups limit to 100, and those 70K people
>> end up belonging to 50 groups on average. Now you've double IM load, and if
>> you remember the days where most group chat sessions failed, it's probably a 
>> quite heavy loaded system.
>>
>> Jabber would have the same issue: how to handle 70K people, many with 
>> multiple
>> conversations and conferences. A small jabber server is easy, but supporting
>> 70K logged in accounts is a serious undertaking.
>> 
>   

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Quiet amendments of TPV (again)

[Tateru Nino]

Interesting changes, worthy of some thoughtful consideration. Have to
run this one back past the lawyers and see what they say.

On 20/04/2010 11:45 PM, Boy Lane wrote:
> As this did not make it into the mailing list yet but is rather important,
> LL changed the TPV policy again, quiet, in the background.
>
> I don't know how this affects the legal validity of that document 
> people agreed by clickwrapping since the new ToS popup, I just
> want to make you aware of that.
>
> Robin ran a diff and the actual changes can be found here:
> http://pastebin.com/Yd1j1EdE
>
> Major changes as I see them, the terms "...you develop and distribute"
> are gone, and one new paragraph was introduced. 
> "Nothing in this Policy is intended to modify the terms of the GPL."
>
> Someone in LL seems to have woken up, but damage is done
> nevertheless.
>
> Boy
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>
>   

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Quiet amendments of TPV (again)

[Tateru Nino]

It's pretty much what the first draft should have looked like. Can't
imagine what interfered with the process to get it in the state it was
originally.

On 25/04/2010 8:58 PM, Nexii Malthus wrote:
> Definitely much more acceptable now.
>
> Thanks Joe
>
> - Nexii
>
> On Sat, Apr 24, 2010 at 2:01 PM, Thickbrick Sleaford
> mailto:thickbrick.sleaf...@gmail.com>>
> wrote:
>
> On Tuesday 20 April 2010 17:02:26 Joe Linden wrote:
> > Boy,
> >
> > There was nothing quiet, or "in the background" about it,
> believe me.  This
> > update is the topic of conversation at the noon PDT brown bag
> I'm hosting
> > today.  The changes were pushed live ahead of the meeting, so
> there would
> >  be no question they are incorporated in to the TPV and TOS,
> both of which
> >  are effective on 4/30.
> >
> > I'll see those of you still interested in the subject at noon here:
> >
> 
> http://maps.secondlife.com/secondlife/Linden%20Estate%20Services/229/230/29
> >
> > -- joe
> >
>
> This is somewhat belated, but: Thank you Joe!
>
> The TPVp is still not ideal from my perspective, but it is now
> certainly
> something I think an open source community can work with.
>
> I still wish it would not force viewers to enforce DRM,
> specifically in cases
> where the user has an appropriate license from the creator that
> supersedes the
> DRM. But I guess this is pretty much a given when a user chooses
> to create
> their content in a grid that is very much DRM-centric. Hopefully
> the DRM will
> be extended soon to include an "export ok" flag, now that the TPVp
> made it a
> critical thing.
>
> Anyway, thanks for listening!
>
> --
> Thickbrick
> ___
> Policies 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

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Thank you for updating the Viewer Directory requirements

[Tateru Nino]

On 29/04/2010 1:43 PM, Latif Khalifa wrote:
> On Wed, Apr 28, 2010 at 11:57 PM, Henri Beauchamp  wrote:
>   
>> In fact, it probably comes from the fact that Linden Lab uses contradictory
>> phrases in the TPV policy and in the TPV directory.
>>
>> Quoting the former:
>>
>> "Unlike the other sections of this Policy, participation in the Viewer
>> Directory is currently not a requirement for connecting to Second Life."
>>
>> And quoting the latter:
>>
>> "Beware of third-party viewers that are not in the Viewer Directory – they
>> have either declined to self-certify or been refused for noncompliance
>> with our policies."
>>
>> So, registering to the directory is clearly not a requirement to be
>> considered as TPV-policy compliant, but on the other hand LL suggests that
>> the viewers which are not in the directory are "dangerous" ones...
>> This is both unfair and very close to pure diffamation.
>> 
> I agree that this is very unfortunate wording on part of Linden Lab. I
> have got a lot of concerned emails and some comments on the site[1]
> "will I be banned if I continue to use Radegast" due to that "beware"
> sentence on the directory page. Some of the emails I got were almost
> panicky. I hope the wording can be changed in order not to cause panic
> and uncertainty among TPV users.
>
> Latif
>
> [1] - http://radegastclient.org/wp/2010/04/radegast-1-16-released/#comments
>   
Yeah, after the blog post from Marty yesterday, there's a lot of chatter
among users who are concerned that they'll be banned if they don't
switch back to an official viewer or one in the directory ASAP. It's
certainly easy enough to see how they got that impression.

-- 
Tateru Nino
Contributing Editor http://massively.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

Re: [opensource-dev] Oh, the drama. (was: Viewer blacklist...)

[Tateru Nino]

The most obvious solution - from where I'm sitting - is to abstract it,
and provide different access methods underneath. The higher levels of
the viewer application should neither know nor care just where the map
tiles are coming from, beyond making an API call to fetch one. Later,
one can look at a method by which a grid service might make certain
representations as to where and how those tiles are located and to be
fetched, but compartmentalizing the hard-wired knowledge (at this stage)
seems to be the best option, presently.

On 30/04/2010 8:20 PM, Lance Corrimal wrote:
> "patching opensim"...
>
> ...how do you "patch" the people who provide a service for free, to make them 
> rent an expensive distributed storage provider for their map tiles?
> are you going to rent S3 yourself, for your own little local grid?
>
>
>
> bye,
> LC
>
> Am Freitag, 30. April 2010 11:23:59 schrieb Brandon Husbands:
>   
>> Perhaps patching open sim to use the new way? probably the best route to go
>> as it needs to keep up with com changes in the main viewer.
>>
>> On Fri, Apr 30, 2010 at 4:04 AM, Lance Corrimal
>>
>> wrote:
>> 
>>> Am Freitag, 30. April 2010 10:47:27 schrieb Brandon Husbands:
>>>   
>>>> I agree. Thats what i have been trying to say... sighs... Can we get
>>>> back to discussing code now?
>>>> 
>>> with pleasure.
>>>
>>>
>>> any ideas about making SG 1.4 fully opensim-compatible by adding the
>>> "old" way
>>> to fetch map tiles?
>>>
>>>
>>> bye,
>>> LC
>>>
>>>   
>>>> On Fri, Apr 30, 2010 at 3:46 AM, Lance Corrimal
>>>>
>>>> wrote:
>>>> 
>>>>> for crying out loud, could you guys PLEASE move the remainder of that
>>>>> "discussion" to a more suited medium, the "Under the bridge" forum on
>>>>> second
>>>>> citizen comes to mind.
>>>>> ... where the trolls are.
>>>>> http://www.secondcitizen.net/Forum/forumdisplay.php?f=18
>>>>> ___
>>>>> Policies 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
>
>   

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] [POLICY] Configurable HTTP user-agent string

[Tateru Nino]

HTTP cookies were shared across all accounts using a viewer installation
- until recently. It's my understanding that the latest crop of viewer2
viewers keep cookies separate per-account. However unless you're using
one of those newest ones, it's possible to track down alt-accounts or
hotseat users using parcel media streams, shared-media prims or HTTP
links by introducing tracking cookies.

On 6/05/2010 6:54 AM, Tigro Spottystripes wrote:
> I thought cookies weren't shared between accounts even in the same
> machine...are you sure they are?
>
> On 5/5/2010 17:28, Thomas Shikami wrote:
> > Bryon Ruxton schrieb:
> >> Can't we just get an additional AGENT_VIEWER flag via llGetAgentInfo?
> >> Even if not foolproof, it's useful as a factor for legitimate
> security or
> >> warning tools, as well as for stats gathering for 99% of residents.
> >> It seems like a logical solution to me, instead of having to go the
> http
> >> agent route or other hackish solutions.
> >>   
> > Making the http trick obsolete is a good step forward in ensuring
> > privacy and maybe a step forward to some LSL policy. Like TPV policy
> was
> > a start to stop copybot development/distribution. When will LSL being
> > policed about what can be done? LSL can also be used to replicate prim
> > parameters and export/import. And newer tools abusing the llParcelMedia
> > commands can be used to get the IP address of the users and they allow
> > planting cookies into the viewers, that are shared between all accounts.
>
> > Don't get me wrong on here. The hypothetical scenery I'm thinking about
> > is a stalker being friends with a land owner, tracking down the alts of
> > myself to grief me. I am not against banning on the viewer identity.
> > Though alt account information is no one's business until LL makes that
> > information available.
> > ___
> > Policies 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

-- 
Tateru Nino
Contributing Editor http://massively.com/

-- 
Tateru Nino
http://dwellonit.taterunino.net/


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

Re: [opensource-dev] [POLICY] Configurable HTTP user-agent string

[Tateru Nino]

On 6/05/2010 11:32 PM, Argent Stonecutter wrote:
> On 2010-05-06, at 01:23, Ricky wrote:
>   
>> How can that be a source of correlation, unless you are using a viewer
>> that has a userbase of one (yourself and your alts)?
>> 
> When you're gathering information on someone for tracking purposes you  
> don't need certainty. Even a viewer with a few percent of the market  
> can be used to direct suspicion at a new account unless they  
> completely avoid all their old hangouts.
>
> There are precisely four viewers that are common enough that using one  
> wouldn't be a red flag: The current and new Linden viewer, Snowglobe,  
> and Emerald.
>
> People who are currently using other viewers and don't pay attention  
> to the privacy implications of new features (ie, just about anyone)  
> would be wearing a target. New privacy exposures have to be opt-in,  
> not opt-out.
>
> This functionality would have to not just be spoofable, but be off by  
> default and turning it on would be done through a user interface that  
> actually shows you the current string and presents common alternatives.
>
> If you were doing this, then it would be easier, easier to understand,  
> and MUCH more useful to implement a general set of account tags or  
> properties that people could edit at will. This would provide all the  
> functionality people would get from a genuinely secure  
> "llDetectedViewer()" type of API, since viewers could have a nice easy  
> button that sets "Emerald: yes".
>   
I can see value in a viewer being able to advertise (or, I guess
repudiate) capabilities. I imagine that most non-security-related viewer
identification would relate to having a guess at viewer
capabilities/features. Also there's not much value in spoofing viewer
capabilities, since the only person to whose detriment it would be would
be the spoofer's.

Would something like llDetectedViewerCaps() that returned a
well-defined, yet open, capabilities string be potentially more useful
than just asking for the brand of the viewer?

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Open Viewer Development Announcement

[Tateru Nino]

On 17/08/2010 4:56 AM, Oz Linden (Scott Lawrence) wrote:




Will try to come, hoping it's not going to be one of those voice meetings
where non-English people like me can't speak well enough neither understand
what is being said...


This meeting will include voice because it's so time consuming to do 
everything in chat.  We will have someone putting the important points 
into chat as much as possible, and will certainly respond to questions 
in chat.


For anyone who wants to have a separate chat-only meeting at another 
time, I'll be glad to set that up.


Actually, I was thinking about the Americans With Disabilities Act, 
personally. Especially as the anniversary of the Act has just been by. 
Unless text, you know, clearly represents an "unreasonable burden".


--
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] display names = the end of 1.x viewers?

[Tateru Nino]

 What I'm wondering is if it is too late to drop the dot and the 
lower-casing from the user name as used or displayed.


On 18/08/2010 12:55 PM, Kelly Linden wrote:

(lets move this to the scripters list?)

I need to refresh myself on this. There should be 3 names:
user name: latif.khalifa
full name: Latif Khalifa
display name: The Awesome Latif

Most (all?) the existing LSL functions will return the 'full name'. I 
also find it confusing to use Kelly DifferentLastName as an example 
display name. This isn't about picking a new last name. It is about 
being just 'Kelly' or 'Teh Kellz'. Sorry, it was just part of what was 
confusing me about the previous examples.


A new user is:
user name: john1234
full name: john1234 Resident
display name: john

The full name is pretty much only relevant for LSL for legacy 
purposes. We spent quite a bit of time trying to find the right way to 
handle LSL to cause the least amount of breakage. Scripts that parse 
for a space to get a first name should still work, scripts that 
require a unique name should still work, scripts that require names to 
match those stored in a notecard or otherwise stored should still 
work. These seemed the most common cases. Scripts that ask the user to 
enter their name and then check that against a sensor event may 
"break" because what people think of when you ask them for their name 
will change, especially for new users. These scripts will need to be 
updated.


This is probably a good topic for my OH next week, at least the LSL 
specific portion.


 - Kelly

On Tue, Aug 17, 2010 at 7:21 PM, Latif Khalifa <mailto:lati...@streamgrid.net>> wrote:


The big source of confusion regarding scripts is the following line
from the FAQ:

"Your username will automatically be formed from your existing avatar
name in the form of your current Second Life firstname.lastname."

Since existing functions will return username, does that mean they
will return "latif.khalifa". Which is my username, "Latif Khalifa" or
"latif.khalifa"?



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


--
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] display names = the end of 1.x viewers?

[Tateru Nino]

On 18/08/2010 6:50 PM, Lance Corrimal wrote:

On Wednesday 18 August 2010 10:20:03 Henri Beauchamp wrote:



Why restricting new user names to "Resident" ?

It's not a restriction.

the whole thing, as far as i can see, boils down to this:

there's the login, and the display name.

the login is _one_ word, chosen at account creation, and will stay the same
forever. For example, it could be something like andromeda02 or whatever.
the display name can be anything, and can be changed once a week.
So if you would create a new account for whatever reasons, you could choose
feedledumthebard as your login, and set your display name to "Henri Beauchamp
the 2nd."

What will happen to old accounts is that their login will be constructed by
using their avatar name, lowercase, and connecting the two pieces with a dot,
and by default their Display name will be the original avatar name.
That's where we connect with the viewer. Input and presentation. I can't 
say as I'm thrilled by the account name being shown as 'tateru.nino' in 
every place that the account name is displayed (or expected) by the 
viewer. I've got capital letters and a space in my original name, after 
all - and my expectation would be for the account-name to preserve that 
(or if it is transforming it because the schema can't handle an 0x20, to 
conceal that transformation from the viewer presentation layers insofar 
as is possible to do so).


Heck, make my account/login '93ede1c5e1363385eb577efc312ae11d' and I'm 
still just as happy - so long as what is /displayed /and /typed /as my 
account name is still "Tateru Nino"


Having my account name visibly changed as a part of the process 
(regardless of what is or is not done with display names) seems 
unnecessary and lazy.

So, in my case, my login will be lance.corrimal and my dosplay name will be
Lance Corrimal.

and in an old viewer with no display name support it will stay that way.

Now what about the fictive new account that you created?
the login name is feedledumthebard.
the display name is "Henri Beauchamp the 2nd"
and in an old viewer with no support for display names it'll show as:
"feedledumthebard Resident".



It will only make the choice for the first name more dificult, since
"John" will be taken by the first new resident registering it, and then
others will have no other choice than to use numbers or weird characters
to register and we will end up with IRC-like names like John12345 and
John54321, which will make it only more difficult to distinguish all the
Johns from each others in-world (for identification purpose, such as
objects ownership, anti-griefing and stuff).


only for their LOGIN, which will not be the Display Name.

Display names do NOT have to be unique.

Think of display names as "group titles that don't need a group to be in", and
it becomes more clear.

The fact that display names don't have to be unique opens the biggest can of
worms though.

What keeps me from, lets say, creating a throwaway alt, setting its Display
Name to "Stiletto Moody", and hanging out at that famous shoe shop telling
people that the place will close down and that all rights to the designs have
been sold to (whatever the place is that will sell copybotted versions).
Other than the fear of having that throwaway alt getting permanently banned in
maybe a year or two when the g-team gets around to doing it.

What keeps me from setting the display name to the name of a well-known land
baron, hanging out at their hub, telling prospective tenants that there's no
free land but "so and so that we're cooperating with still has a few free
homesteads"...?

The fact that the login name can be seen in the profile does NOT mean that
people will understand the difference, or pay attention to it.

Keep in mind that there are LONG TIME RESIDENTS who still don't know how to
read a notecard. That paints a pretty black prospect of the mental capacities
of the generic noobie...



IF those display names arenot shot down before rollout (hopefully they are)
there needs a BIG section on discovery island covering them, and how to avoid
being scammed.


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



--
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Open Viewer Development Announcement

[Tateru Nino]

  You can also revoke the copyright assignment at (almost) any time.

On 19/08/2010 6:57 AM, Dickson, Mike (ISS Software) wrote:
> There are loads of open source projects that are LGPL (in whole or part) and 
> that require a contributors agreement. Joomla, Alfresco, OpenChange, 
> Evolution, etc.  It's a very common practice when a legal entity is the 
> corporate sponsor for the project.  The only impairment here is the constant 
> bickering over useless details.  Either you want to contribute or you don't.  
> If you do LL is the copyright holder and has every right to insist you sign a 
> contributors agreement in order to make code contributions so that they can 
> administer the project.
>
> Mike
>
> -Original Message-
> From: opensource-dev-boun...@lists.secondlife.com 
> [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Mike 
> Monkowski
> Sent: Wednesday, August 18, 2010 4:52 PM
> To: Henri Beauchamp
> Cc: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Open Viewer Development Announcement
>
> Henri Beauchamp wrote:
>> SL is the ONLY so-called (but actually still not, obviously: a Canada-Dry
>> LGPL, perhaps ?) LGPL Open Source project requiring a License agreement
>> from its contributors !!!  This makes strictly no sense and is a clear
>> impairement.
>>
>> I'd also be curious to know any other of your "good and valid reasons"...
> I, obviously, am not in a position to speak for Linden Lab, but let me
> offer my opinion.  This project is somewhat different from most LGPL
> projects in that if there is no CA, it places Linden in the position of
> being sued for copyright infringement if someone contributes plagiarized
> code.  Most LGPL projects don't have a corporate owner with money worth
> suing for.
>
> Mike
> ___
> Policies 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
>

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Open Viewer Development Announcement

[Tateru Nino]

On 20/08/2010 3:16 AM, Henri Beauchamp wrote:
> On Wed, 18 Aug 2010 15:04:21 -0400, Oz Linden (Scott Lawrence) wrote:
>
>>On 2010-08-18 14:14, Aidan Thornton wrote:
>>> On 8/18/10, Oz Linden (Scott Lawrence)   wrote:
>>>> While there were some good things about the v1 implementation of pie
>>>> menus, they also had some flaws - such as not opening a submenu centered
>>>> on the mouse click.
>>> I actually puzzled over this a bit when I first realised that Second
>>> Life's pie menus worked this way. Originally, the pie menus worked
>>> well when you didn't click too close to the edge of the screen but
>>> didn't actually open under the mouse cursor if you did. Since the
>>> "More..." item is sensibly always the southmost one, opening new
>>> submenus centered on the mouse would cause the pie menu to drift down
>>> the screen until it hit the bottom and caused problems.
>>>
>>> Also, opening the submenu at the same location has the nice
>>> side-effect that the mouse remains over the "More..." option for the
>>> pie menus that are nested 3 or more levels deep.
>>>
>>> What I have been contemplating is how to make it possible to open the
>>> next layer of a pie menu without moving the mouse at all. Sadly, it'd
>>> probably break too much from normal UI conventions to be worth doing.
>> If I understood him correctly, what Q seemed to think was the right
>> behavior is:
>>
>>  * The first mouse-down opens the pie centered on the mouse location,
>>so no choice is under the mouse
>>  * If the choice is a submenu, each new menu is also centered on the
>>mouse
>>
>> that way, you are never making a choice within the submenu if you
>> accidentally double click, because the center is never a choice.  this
>> does mean that the nested menus 'creep', but that has the effect that
>> each nested choice is a 'gesture-like' unique series of clicks.
> A smarter approach would be to automatically move the cursor itself to
> the center of the pie menu (without moving the latter to avoid an
> annoying "drifting" effect) when you click on a sub-menu.
>
> However, I never found the fact that the pie menu was not centered on
> the cursor after a click on a sub-menu item to be an hinderance, since
> the whole idea about pie menus is that you quickly get your "muscle
> memory" trained and don't even have to look at the menu any more after
> you are trained. For example, my "muscles know" that to delete an
> in-world object I must right click on it, then move south, left click
> (for "More>"), and move north east and left click again (for Delete).
> With the new method, I'd simply have to replace "north east" with
> "east" in my muscle memory (which would make me miss quite a number
> of clicks at first, since this memory has been trained and used for
> almost 4 years now, so if you reimplement pie-menus in this new way,
> I'd appreciate a debug option to prevent the auto-recentering of the
> cursor)...
For a while, I was somewhat spoiled by colour-coded, multi-layered 
concentric radial menus. A chance to preview the whole menu tree with a 
little mouse-wiggling before selecting an option.

A bit like this: 
http://3.bp.blogspot.com/_6C7jhrvrP14/SCIXQ0vvNFI/AJM/cCtvGNWR0co/s400/menu.png

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] display names = the end of 1.x viewers?

[Tateru Nino]

On 20/08/2010 2:51 PM, Baloo Uriza wrote:

On Thu, 19 Aug 2010 16:53:18 -0700, Daniel Smith wrote:


On Thu, Aug 19, 2010 at 3:28 PM, Baloo Uriza
  wrote:


On Thu, 19 Aug 2010 10:15:14 -0700, Daniel Smith wrote:


I'll ask the Lindens a direct question:

What will you do to prevent others from using my username as their
displayname?

I'm going to hazard to guess the answer is "nothing."  If anything,
this brings SL into better parity with the real world, where many
people might have the same name.



Thanks for playing.  Just sign up last week?

Given that my last name is Uriza and Display Names aren't rolled out yet
to my knowledge, I believe it's clear I did not.


If they do nothing, situations will occur that will end up in court.
Bet on it.

Sure, but even if that's the case, I can't fathom a single situation
(other than a Linden employee abusing Display Names) that would cause the
Lindens to be named as a defendant (and not get laughed out of court by
the judge).
Ah, perhaps I can help there. /Marvel vs NCsoft/ (docket: CV 
04-9253RGKPLAX, 9 March, 2005, California district court).


Marvel (back before they had Disney's legion of undead lawyers) sued 
NCsoft over City of Heroes, because the character creator allowed users 
to create avatars that had similar likenesses to or similar names to 
Marvel trademarks. NCsoft eventually capitulated and settled.


--
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Display names, again.

[Tateru Nino]

  Forwarding your questions through the PR channels, Lance. Although, 
from the documentation provided by the Lab so far, the answer to 
question one is 'no'.

On 20/08/2010 4:38 PM, Lance Corrimal wrote:
> Is it just me or did the lindens stop replying to this topic?
>
>
> ok, lets try this again.
>
> Here are some distict questions, and I would like to see distinct
> "yes" or "no" answers from linden labs employees, and I would like it
> a lot if, in case no one of the lindens on the list can answer my
> questions in such a disticnt manner, the questions be forwarded to
> someone who can.
>
>
> 1. Will there be procedures in place to prevent someone else to use my
> true avatar name as their display name?
>
> 2. Will there be procedures in place to prevent someone from using a
> display name that might be different from my true avatar name but for
> all visual verification looks like it, given how there are unicode
> characters that have a different code but look like regular
> characters?
>
> 3. Will there be procedures in place to prevent the case where someone
> uses a copyrighted name of a fictional character (like, for example,
> "Mickey Mouse" or "Clark Kent") as their display name?
>
> 4. If the answer to any of the above is not a clear and loud yes: Will
> there be procedures in place to protect the original holder of any
> true avatar name from legal damages after someone used their name as
> their display name for fraudulent uses?
>
> bye,
> LC
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>

-- 
Tateru Nino
Contributing Editor http://massively.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

Re: [opensource-dev] Display names, again.

[Tateru Nino]

On 20/08/2010 6:08 PM, Opensource Obscure wrote:
> On Fri, 20 Aug 2010 16:44:47 +1000, Tateru Nino
> wrote:
>> Forwarding your questions through the PR channels, Lance. Although,
>> from the documentation provided by the Lab so far, the answer to
>> question one is 'no'.
>
> a few email messages ago, Kelly replied to Ann Otoole:
>
> "No new user can create ann.otoole OR annotoole as a username,
> that name is taken by you"
>
> Isn't this the point of question one?

No, Kelly's answer was about account names. Lance's question was about 
whether a Display Name could be the same (for varying values of the 
same) as an Account Name.
>
> Questions 2-3 are not new.
> Not new are stories of users abusing account names by exploiting
> similarity between 'l' and "I" - or some other letters. The font
> choice is to blame in such a case, and this has been reported to
> PJIRA. Nothing new.
>
> Question 4 seems even naive if I get it right - Legal
> protections? Is this that's being asked?
> I'm not aware of other online service providers who put
> procedures in place to protect their users from fraudulent use.
> Can we name some? Thanks.
>
> If you're looking for legal protection try registering your
> avatar name as a trademark, as other SL users did.
>
>
>> On 20/08/2010 4:38 PM, Lance Corrimal wrote:
>>> Is it just me or did the lindens stop replying to this topic?
> It is just you:
> https://lists.secondlife.com/pipermail/opensource-dev/2010-August/002649.html
>
> (or maybe I'm missing some rule about how fast Lindens must reply)
>
> Opensource Obscure
>
>
>>> ok, lets try this again.
>>>
>>> Here are some distict questions, and I would like to see distinct
>>> "yes" or "no" answers from linden labs employees, and I would like it
>>> a lot if, in case no one of the lindens on the list can answer my
>>> questions in such a disticnt manner, the questions be forwarded to
>>> someone who can.
>>>
>>>
>>> 1. Will there be procedures in place to prevent someone else to use my
>>> true avatar name as their display name?
>>>
>>> 2. Will there be procedures in place to prevent someone from using a
>>> display name that might be different from my true avatar name but for
>>> all visual verification looks like it, given how there are unicode
>>> characters that have a different code but look like regular
>>> characters?
>>>
>>> 3. Will there be procedures in place to prevent the case where someone
>>> uses a copyrighted name of a fictional character (like, for example,
>>> "Mickey Mouse" or "Clark Kent") as their display name?
>>>
>>> 4. If the answer to any of the above is not a clear and loud yes: Will
>>> there be procedures in place to protect the original holder of any
>>> true avatar name from legal damages after someone used their name as
>>> their display name for fraudulent uses?
>>>
>>> bye,
>>> LC
>>> ___
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>>> Please read the policies before posting to keep unmoderated posting
>>> privileges
>>>

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Display names, again.

[Tateru Nino]

On 20/08/2010 6:35 PM, Baloo Uriza wrote:
> On Fri, 20 Aug 2010 09:22:30 +0200, Lance Corrimal wrote:
>
>> On Friday 20 August 2010 08:44:47 Tateru Nino wrote:
>>>Forwarding your questions through the PR channels, Lance. Although,
>>> from the documentation provided by the Lab so far, the answer to
>>> question one is 'no'.
>>
>> http://en.wikipedia.org/wiki/Aiding_and_abetting ???
> Common carrier.
There's a strong case that the Lab no longer has common carrier status, 
due to frequent, unprompted exercises of editorial control (though it 
might be seeking to regain it). Either way, though - not really a topic 
for this particular list.

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Draw Distance

[Tateru Nino]

  I probably use the draw-distance slider more often than any other UI 
widget. I'd probably map it to my mouse's scroll-wheel, if I could.

On 22/08/2010 10:31 AM, Suz Dollar wrote:
> This is one concept that I have wanted for at least four years in SL. I
> change draw distance multiple times a day depending on where I"m
> visiting. Many of my own estate regions I can use a full powered 512
> draw distance. Going to my public sandbox, however, requires an instant
> drop to 128 or lower. Visiting my old 'hometown' of Caledon, mandates
> the same. And I have to be honest, the places I can still use 512 draw
> distance with viewer 2.x has dropped dramatically. I now usually can't
> use higher than 256 yet have been assured since the first beta release
> that there should be no performance difference between 1.23 and 2.x with
> regard to graphics. An easily accessible way to change draw distance
> would be awesome. I'm also frustrated that its so much harder with the
> slider to hit the magic numbers: 64, 96, 128,  256 you get the idea.
> But if the slider were at least out on the main UI somewhere, my own
> preference being up in the navigation area, but anywhere directly
> accessible, would be AWESOME.
>
> Char
>
>
> a...@skyhighway.com wrote:
>> There was some talk lately about draw distance.  i mentioned that from my
>> place if i have my draw distance turned up over about 150 i can almost
>> count on crashing when i tp.  i'm really sorry i can't describe the
>> problem any better than that.  If someone wants to tell me how i could
>> understand it better, i'd love to listen?
>>
>> Anyway, i mentioned in mail to this list that it would be really cool if
>> there were an onscreen widget like the movement&  camera controls that
>> made draw distance a lot easier to change.  Please forgive me for not
>> having already figured out how to do that myself.  Just sayin' tho, it
>> would be really nice if, like for instance, Snowglobe had either a mouse
>> gesture, keyboard short cut, or onscreen widget (all three?) for rapidly,
>> easily changing draw distance,  i think it's a function that lots of
>> people would use heavily.  i know there's performance concerns, but if,
>> for instance, the onscreen widget included a simple performance bar
>> indicator that went down as the draw distance was turned up, that would
>> communicate pretty well to all the people who didn't know better for
>> whatever reason.
>>
>> The tp crash i get is just one more reason to make the setting easy to
>> deal with.  Besides, to me it seems like such a natural part of camera
>> controls that i don't know why it's not there already?  If it was me
>> adding the feature i'd put it in the camera controls widget.  i'd been
>> using SL for several months before i even realized that draw distance was
>> configurable.
>>
>> Thanks for listening!
>>
>> ___
>> Policies 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
>

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

[Tateru Nino]

 Arabella has also resigned.

On 23/08/2010 3:32 AM, Jesse Barnett wrote:

Fractured has stepped down and out of the Emerald picture

http://blog.modularsystems.sl/2010/08/22/emerald-off-with-his-head/

But it is painfully obvious that the comments are being heavily 
moderated and I know that neither of mine have gotten through.


The Phox is still in the hen house and it is going to take much more 
then this token response to restore confidence. Anyone watching the 
videos and listening to their voices can see that a 
complete reorganization needs to be done and transparency demonstrated 
and verified.


I hope that the upper echelons of Linden Lab are not fooled by the 
blog post and instead demand that more action be taken. At the bare 
minimum, they need to be delisted until real change has been shown.


Ignoring this and giving the all clear with no other action taken on 
the part of Linden Lab will instead demonstrate that the TPV is a 
worthless scrap of paper.


Jesse Barnett


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


--
Tateru Nino
Contributing Editor http://massively.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

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

[Tateru Nino]

  And my own writeup: 
http://dwellonit.taterunino.net/2010/08/22/arabella-steadham-asked-to-lie-about-emerald-viewer/

On 23/08/2010 3:15 PM, Miro Collas wrote:
> Yes she did. Here's the interview from treet.tv:
> http://treet.tv/people/gracer/blog/20100822/audio-excerpt-interview-arabella-and-jessica
>  
>
>
> See also:
> http://blog.modularsystems.sl/2010/08/22/emerald-resurgence/
>
>
> On 08/23/2010 12:17 AM, Tateru Nino wrote:
>> Sure do. Although apparently she un-resigned shortly after, which I do
>> not yet have a cite for. Still waking up.
>>
>> http://dwellonit.taterunino.net/2010/08/22/hijack-hijinks/
>>
>>
>> On 23/08/2010 5:49 AM, Miro Collas wrote:
>>> Do you have a cite for that, Tateru? Not saying it is false, I'd just
>>> like to see it in context if possible.
>>>
>>> On 08/22/2010 01:38 PM, Tateru Nino wrote:
>>>> Arabella has also resigned.
>>>>
>>>> On 23/08/2010 3:32 AM, Jesse Barnett wrote:
>>>>> Fractured has stepped down and out of the Emerald picture
>>>>>
>>>>> http://blog.modularsystems.sl/2010/08/22/emerald-off-with-his-head/
>>>>>
>>>>> But it is painfully obvious that the comments are being heavily
>>>>> moderated and I know that neither of mine have gotten through.
>>>>>
>>>>> The Phox is still in the hen house and it is going to take much more
>>>>> then this token response to restore confidence. Anyone watching the
>>>>> videos and listening to their voices can see that a complete
>>>>> reorganization needs to be done and transparency demonstrated and
>>>>> verified.
>>>>>
>>>>> I hope that the upper echelons of Linden Lab are not fooled by the
>>>>> blog post and instead demand that more action be taken. At the bare
>>>>> minimum, they need to be delisted until real change has been shown.
>>>>>
>>>>> Ignoring this and giving the all clear with no other action taken on
>>>>> the part of Linden Lab will instead demonstrate that the TPV is a
>>>>> worthless scrap of paper.
>>>>>
>>>>> Jesse Barnett
>>>>>
>>>>>
>>>>> ___
>>>>> Policies and (un)subscribe information available here:
>>>>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>>>>> Please read the policies before posting to keep unmoderated posting
>>>>> privileges
>>>> -- 
>>>> Tateru Nino
>>>> Contributing Editorhttp://massively.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
>>>
>>
>
>

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

[Tateru Nino]

  And now, perhaps, we can get back to the important stuff, like the 
viewer itself. ;)

On 23/08/2010 3:15 PM, Miro Collas wrote:
> Yes she did. Here's the interview from treet.tv:
> http://treet.tv/people/gracer/blog/20100822/audio-excerpt-interview-arabella-and-jessica
>  
>
>
> See also:
> http://blog.modularsystems.sl/2010/08/22/emerald-resurgence/
>
>
> On 08/23/2010 12:17 AM, Tateru Nino wrote:
>> Sure do. Although apparently she un-resigned shortly after, which I do
>> not yet have a cite for. Still waking up.
>>
>> http://dwellonit.taterunino.net/2010/08/22/hijack-hijinks/
>>
>>
>> On 23/08/2010 5:49 AM, Miro Collas wrote:
>>> Do you have a cite for that, Tateru? Not saying it is false, I'd just
>>> like to see it in context if possible.
>>>
>>> On 08/22/2010 01:38 PM, Tateru Nino wrote:
>>>> Arabella has also resigned.
>>>>
>>>> On 23/08/2010 3:32 AM, Jesse Barnett wrote:
>>>>> Fractured has stepped down and out of the Emerald picture
>>>>>
>>>>> http://blog.modularsystems.sl/2010/08/22/emerald-off-with-his-head/
>>>>>
>>>>> But it is painfully obvious that the comments are being heavily
>>>>> moderated and I know that neither of mine have gotten through.
>>>>>
>>>>> The Phox is still in the hen house and it is going to take much more
>>>>> then this token response to restore confidence. Anyone watching the
>>>>> videos and listening to their voices can see that a complete
>>>>> reorganization needs to be done and transparency demonstrated and
>>>>> verified.
>>>>>
>>>>> I hope that the upper echelons of Linden Lab are not fooled by the
>>>>> blog post and instead demand that more action be taken. At the bare
>>>>> minimum, they need to be delisted until real change has been shown.
>>>>>
>>>>> Ignoring this and giving the all clear with no other action taken on
>>>>> the part of Linden Lab will instead demonstrate that the TPV is a
>>>>> worthless scrap of paper.
>>>>>
>>>>> Jesse Barnett
>>>>>
>>>>>
>>>>> ___
>>>>> Policies and (un)subscribe information available here:
>>>>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>>>>> Please read the policies before posting to keep unmoderated posting
>>>>> privileges
>>>> -- 
>>>> Tateru Nino
>>>> Contributing Editorhttp://massively.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
>>>
>>
>
>

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] separation between login id and publicly visible id(s)

[Tateru Nino]

On 24/08/2010 4:51 AM, Joel Foner wrote:


As Josh and others have said, one of the things we'd need is a
unique secret account identifier. Unfortunately the only existing
account datum which might work here is email address, and that's
not unique, though we're starting to think that it really should be


Just a quick note... email addresses change fairly regularly. Basing 
the permanent unique account identifier on a transient token seems 
bound to create problems in the longer term due to user movements from 
one email address to another, and old addresses become invalid and 
even forgotten by users.


Actually, I remember that the RegAPI (for a long time - don't know if it 
still does) wouldn't accept an email address that had /ever/ been used 
for registration of an account previously. Ran into that one during some 
client work.


--
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Display names, again.

[Tateru Nino]

On 24/08/2010 5:05 AM, Oz Linden (Scott Lawrence) wrote:

On 2010-08-23 14:57, Will wrote:
Oz, what is Linden Labs position on Emerald and will they be making a 
public announcement? (not a lawyer just a concerned resident, 
remember them?)


This is not the place to make any such statement.

I believe that one will be coming out in due time, but decline to 
predict its timing or content.
I'm already waiting on an official response from the Lab spokespersons 
(since last week). I'll blog it when it comes through.


--
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Draw Distance

[Tateru Nino]

On 24/08/2010 6:06 AM, Martin Spernau wrote:
> Am 23.08.2010 um 21:39 schrieb Arrehn Oberlander:
>> This is just off the top of my head. Many of these depend on user's
>> preference for framerate vs scene details at a moment in time, and
>> can't be reliably guessed purely from inworld behavior (although there
>> are hints, I will grant).
>
> Isn't that much like in photography, where you have different kinds of
> 'automatic' (shutter speed vc aperture auto) ... and depending on your
> creatice needs the one is betzer than the other and vice versa
> Maybe the 'optimize for high fps' and 'optimize for view distance'
> would be the viewer equivalöents
Something very much like that, yes. I've only got about six common 
settings, but I might use all of them in the space of five minutes.

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Draw Distance - TPV Solution Example - SLIDER Correction

[Tateru Nino]

On 24/08/2010 4:49 PM, Lance Corrimal wrote:
> Am Tuesday 24 August 2010 schrieb Science Fiction Computer - SCi-Fi
> PC:
>> Apologies all, correction, the SLIDER is located, off-center, TOP
>> RIGHT.
>
> you mean there is one in the original skin too? neat.
>

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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

Re: [opensource-dev] Final build for Snowstorm Sprint 2

[Tateru Nino]

  Anyone else seeing shared media rendering messed up on this build 
(particularly scrollable pages and the like), or is it just me?

It appears as if the media rendering is offset on the prim (rolled 
upwards about 25%, with the top portion at the bottom). Scroll that and 
it seems to remain consistent. If it's just me, I'll see if I can 
establish a proper repro.

On 1/09/2010 12:05 AM, Oz Linden (Scott Lawrence) wrote:
>Here's a pointer to our final build for Snowstorm sprint 2:
>
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/rev/208771/index.html
>
> barring something catastrophic, that should be posted to secondlife.com
> as soon as we can verify that the requisite infrastructure is in place.
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>

-- 
Tateru Nino
http://dwellonit.taterunino.net/

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