Re: [opensource-dev] Review Request: CHOP-629 symbol information for llcommon.dll is missing both in the debugger and in crash reports

[Boroondas Gupte]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/281/#review653
---



indra/llcommon/CMakeLists.txt


Naive question: Is there a reason not to add /DEBUG also when NOT 
LLCOMMON_LINK_SHARED?


- Boroondas


On April 26, 2011, 5:48 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/281/
> ---
> 
> (Updated April 26, 2011, 5:48 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Somewhere in the VS2010 transition, the default conventions changed for how 
> .pdb files get generated on shared library targets.  This fix explicitly sets 
> the /DEBUG flag for the linker on the llcommon target.
> 
> 
> This addresses bug CHOP-629.
> http://jira.secondlife.com/browse/CHOP-629
> 
> 
> Diffs
> -
> 
>   indra/llcommon/CMakeLists.txt UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/281/diff
> 
> 
> Testing
> ---
> 
> I tested locally in the debugger, but I did not test crash reports.  We 
> should find a way to test that once my TC build completes.
> 
> 
> Thanks,
> 
> Brad
> 
>

___
Policies 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-25608 error on shutdown due to buffer overrun in LLVFS::audit

[Boroondas Gupte]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/278/#review654
---



indra/llvfs/llvfs.cpp


When index_size == 0, wouldn't it be more appropriate to skip the steps 
that require taking the address of element 0? They'd be nil operations in that 
case, anyway, wouldn't they?



indra/llvfs/llvfs.cpp


e.g. here we could extend the condition to
if (!buffer.empty() && (fread(&buffer[0], 1, index_size, mIndexFP) != 
index_size))



indra/llvfs/llvfs.cpp


If index_size == 0, we don't even enter this loop ...



indra/llvfs/llvfs.cpp


... so taking the address here shouldn't be problematic.


Finally, if we are only ever accessing the underlying memory directly (as seems 
to be the case here), why use a std::vector as buffer instead of an array?

- Boroondas


On April 26, 2011, 5:31 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/278/
> ---
> 
> (Updated April 26, 2011, 5:31 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fix for a minor buffer overrun on shutdown in LLVFS::audit.
> 
> 
> This addresses bug VWR-25608.
> http://jira.secondlife.com/browse/VWR-25608
> 
> 
> Diffs
> -
> 
>   indra/llvfs/llvfs.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/278/diff
> 
> 
> Testing
> ---
> 
> I tested using the Microsoft Debug Heap and confirmed that this allows the 
> Debug Heap to shut down without errors.
> 
> 
> Thanks,
> 
> Brad
> 
>

___
Policies 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-25610 LLControlGroup::loadFromFile makes unnecessary copies of large LLSD objects

[Boroondas Gupte]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/280/#review655
---

Ship it!


The nice thing about this change is that is has to be correct[*] if it still 
compiles. (And it does, I checked :-)

3 minor considerations:


indra/llxml/llcontrol.cpp


1) Any reason not to do the same for name?
2) Remove space between "const" and "&", so that it's easer to visually 
distinguish from binary operator &
3) LLSD::map_const_iterator seems to support operator ->, so we could write 
itr->second instead of (*itr).second .


[*] Assuming the data referenced by control_map isn't changed by other threads 
meanwhile. But I guess that'd also be necessary for copying it correctly, isn't 
it?

- Boroondas


On April 26, 2011, 5:36 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/280/
> ---
> 
> (Updated April 26, 2011, 5:36 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Unnecessary copying was slowing down debugging of STORM-1141.
> 
> 
> This addresses bug VWR-25610.
> http://jira.secondlife.com/browse/VWR-25610
> 
> 
> Diffs
> -
> 
>   indra/llxml/llcontrol.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/280/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Brad
> 
>

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

[opensource-dev] Request for comment on these JIRA reports

[Opensource Obscure]

Here are a few JIRA issues I recently focused on
where a comment from LL would be much appreciated.


* https://jira.secondlife.com/browse/SVC-2283
Sending postcards severely slows simulator performance
- this issue should be closed (but I can't)

* https://jira.secondlife.com/browse/VWR-25506
Investigate restrictions on storing and exchanging inventory items
within prims and notecards
- are the published results useful? should testing go on?

* https://jira.secondlife.com/browse/SVC-6898
Switching language in preferences creates new calling cards folders
for each language
- request for a comment about proposed solution for those users
who currently have duplicate, undeletable folders in Inventory

* https://jira.secondlife.com/browse/VWR-25566
New error message mentions "need to restart Second Life and
log into a new region for the next 30 minutes to an hour"
- could we have more details about this new scenario?

* https://jira.secondlife.com/browse/SVC-5387
Snapshot to postcard failure
- how to provide more helpful feedback?

* https://jira.secondlife.com/browse/SOCIAL-868
Save-Publish Snapshots to Facebook, Twitter, KOINUP, Photobucket, Flickr, etc.
- this request has been closed and we'd like to know why


Opensource Obscure
--
http://twitter.com/oobscure - http://opensourceobscure.com/lol
Join this group to discuss SL Viewer 2: http://j.mp/slv2group
___
Policies 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] Request for comment on these JIRA reports

[Andrew Meadows]

Opensource -

I don't know about the other issues, but the two postcard problems are on my
team's short list for the next two weeks, along with a bunch of other stuff.
I  closed SVC-2283 but left the internal issue open with a comment suggesting
that we at least take a swing at reproducing it and only close it if we fail.

SVC-5387 is on the short list.  Hopefully we'll get to it.

- Andrew

On 04/27/2011 06:41 AM, Opensource Obscure wrote:
> Here are a few JIRA issues I recently focused on
> where a comment from LL would be much appreciated.
>
>
> * https://jira.secondlife.com/browse/SVC-2283
> Sending postcards severely slows simulator performance
> - this issue should be closed (but I can't)
>
> * https://jira.secondlife.com/browse/VWR-25506
> Investigate restrictions on storing and exchanging inventory items
> within prims and notecards
> - are the published results useful? should testing go on?
>
> * https://jira.secondlife.com/browse/SVC-6898
> Switching language in preferences creates new calling cards folders
> for each language
> - request for a comment about proposed solution for those users
> who currently have duplicate, undeletable folders in Inventory
>
> * https://jira.secondlife.com/browse/VWR-25566
> New error message mentions "need to restart Second Life and
> log into a new region for the next 30 minutes to an hour"
> - could we have more details about this new scenario?
>
> * https://jira.secondlife.com/browse/SVC-5387
> Snapshot to postcard failure
> - how to provide more helpful feedback?
>
> * https://jira.secondlife.com/browse/SOCIAL-868
> Save-Publish Snapshots to Facebook, Twitter, KOINUP, Photobucket, Flickr, etc.
> - this request has been closed and we'd like to know why
___
Policies 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] Request for comment on these JIRA reports

[Joshua Bell]

On Wed, Apr 27, 2011 at 6:41 AM, Opensource Obscure <
opensourceobsc...@gmail.com> wrote:

>
> * https://jira.secondlife.com/browse/SVC-5387
> Snapshot to postcard failure
> - how to provide more helpful feedback?
>

Sorry for not catching up with you in-world on this one, OO.  (And sorry for
the dupe email, I meant to send this to the list)

If you can repro, check out your viewer log and see if it's reporting more
detail about the failure, specifically an HTTP error code and message.

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

Re: [opensource-dev] Review Request: CHOP-629 symbol information for llcommon.dll is missing both in the debugger and in crash reports

[Brad Kittenbrink]

> On April 27, 2011, 2:16 a.m., Boroondas Gupte wrote:
> > indra/llcommon/CMakeLists.txt, lines 262-278
> > 
> >
> > Naive question: Is there a reason not to add /DEBUG also when NOT 
> > LLCOMMON_LINK_SHARED?

The /DEBUG linker flag doesn't really apply for static libraries since the 
linker doesn't run for static libraries on windows.  The debug information is 
already embedded in our .lib static libraries on windows.


- Brad


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/281/#review653
---


On April 26, 2011, 5:48 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/281/
> ---
> 
> (Updated April 26, 2011, 5:48 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Somewhere in the VS2010 transition, the default conventions changed for how 
> .pdb files get generated on shared library targets.  This fix explicitly sets 
> the /DEBUG flag for the linker on the llcommon target.
> 
> 
> This addresses bug CHOP-629.
> http://jira.secondlife.com/browse/CHOP-629
> 
> 
> Diffs
> -
> 
>   indra/llcommon/CMakeLists.txt UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/281/diff
> 
> 
> Testing
> ---
> 
> I tested locally in the debugger, but I did not test crash reports.  We 
> should find a way to test that once my TC build completes.
> 
> 
> Thanks,
> 
> Brad
> 
>

___
Policies 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: CHOP-629 symbol information for llcommon.dll is missing both in the debugger and in crash reports

[Boroondas Gupte]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/281/#review657
---

Ship it!


>The /DEBUG linker flag doesn't really apply for static libraries since the 
> linker doesn't run for static libraries on windows.  The debug information is 
> already embedded in our .lib static libraries on windows.

Ah, ok.

- Boroondas


On April 26, 2011, 5:48 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/281/
> ---
> 
> (Updated April 26, 2011, 5:48 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Somewhere in the VS2010 transition, the default conventions changed for how 
> .pdb files get generated on shared library targets.  This fix explicitly sets 
> the /DEBUG flag for the linker on the llcommon target.
> 
> 
> This addresses bug CHOP-629.
> http://jira.secondlife.com/browse/CHOP-629
> 
> 
> Diffs
> -
> 
>   indra/llcommon/CMakeLists.txt UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/281/diff
> 
> 
> Testing
> ---
> 
> I tested locally in the debugger, but I did not test crash reports.  We 
> should find a way to test that once my TC build completes.
> 
> 
> Thanks,
> 
> Brad
> 
>

___
Policies 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-25608 error on shutdown due to buffer overrun in LLVFS::audit

[Brad Kittenbrink]

> On April 27, 2011, 3:30 a.m., Boroondas Gupte wrote:
> > indra/llvfs/llvfs.cpp, lines 1716-1717
> > 
> >
> > When index_size == 0, wouldn't it be more appropriate to skip the steps 
> > that require taking the address of element 0? They'd be nil operations in 
> > that case, anyway, wouldn't they?

In theory, you're right, but my intent was to make the minimally invasive 
change that would fix the error, and be sure to preserve all existing 
behaviors.  I was hesitant to engage in any more extensive refactoring without 
a good plan for how we want to test this subsystem.


> On April 27, 2011, 3:30 a.m., Boroondas Gupte wrote:
> > indra/llvfs/llvfs.cpp, lines 1719-1723
> > 
> >
> > e.g. here we could extend the condition to
> > if (!buffer.empty() && (fread(&buffer[0], 1, index_size, 
> > mIndexFP) != index_size))

We certainly could, but I'm not convinced that that's better.


On April 27, 2011, 3:30 a.m., Brad Kittenbrink wrote:
> > Finally, if we are only ever accessing the underlying memory directly (as 
> > seems to be the case here), why use a std::vector as buffer instead of an 
> > array?

I can't speak to the intent of the original author of this code, but I always 
use vectors for dynamically sized arrays, as they automatically free the 
buffer.  Using new[] or malloc is far more error prone, even when using 
std::auto_ptr or boost::scoped_ptr for RAII.


- Brad


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/278/#review654
---


On April 26, 2011, 5:31 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/278/
> ---
> 
> (Updated April 26, 2011, 5:31 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fix for a minor buffer overrun on shutdown in LLVFS::audit.
> 
> 
> This addresses bug VWR-25608.
> http://jira.secondlife.com/browse/VWR-25608
> 
> 
> Diffs
> -
> 
>   indra/llvfs/llvfs.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/278/diff
> 
> 
> Testing
> ---
> 
> I tested using the Microsoft Debug Heap and confirmed that this allows the 
> Debug Heap to shut down without errors.
> 
> 
> Thanks,
> 
> Brad
> 
>

___
Policies 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-25610 LLControlGroup::loadFromFile makes unnecessary copies of large LLSD objects

[Brad Kittenbrink]

> On April 27, 2011, 4:16 a.m., Boroondas Gupte wrote:
> > indra/llxml/llcontrol.cpp, lines 866-867
> > 
> >
> > 1) Any reason not to do the same for name?
> > 2) Remove space between "const" and "&", so that it's easer to visually 
> > distinguish from binary operator &
> > 3) LLSD::map_const_iterator seems to support operator ->, so we could 
> > write itr->second instead of (*itr).second .

1) Premature optimization is the root of all evil.  In all seriousness though, 
I found that the recursive LLSD copying was causing a significant number of 
memory allocations.  I didn't notice the name copying in the profiling, so I 
didn't look at it.  Making this consistent is probably a good idea.
2) I think this is a bad idea, that would be far less readable imho.
3) I'd be fine with this change at some point, but I don't think it really 
matters.


On April 27, 2011, 4:16 a.m., Brad Kittenbrink wrote:
> > [*] Assuming the data referenced by control_map isn't changed by other 
> > threads meanwhile. But I guess that'd also be necessary for copying it 
> > correctly, isn't it?

Correct, there are no other threads that can interfere with 
LLControlGroup::loadFromFile


- Brad


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/280/#review655
---


On April 26, 2011, 5:36 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/280/
> ---
> 
> (Updated April 26, 2011, 5:36 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Unnecessary copying was slowing down debugging of STORM-1141.
> 
> 
> This addresses bug VWR-25610.
> http://jira.secondlife.com/browse/VWR-25610
> 
> 
> Diffs
> -
> 
>   indra/llxml/llcontrol.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/280/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Brad
> 
>

___
Policies 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-25608 error on shutdown due to buffer overrun in LLVFS::audit

[Boroondas Gupte]

> On April 27, 2011, 3:30 a.m., Boroondas Gupte wrote:
> > indra/llvfs/llvfs.cpp, lines 1716-1717
> > 
> >
> > When index_size == 0, wouldn't it be more appropriate to skip the steps 
> > that require taking the address of element 0? They'd be nil operations in 
> > that case, anyway, wouldn't they?
> 
> Brad Kittenbrink wrote:
> In theory, you're right, but my intent was to make the minimally invasive 
> change that would fix the error, and be sure to preserve all existing 
> behaviors.  I was hesitant to engage in any more extensive refactoring 
> without a good plan for how we want to test this subsystem.

Fair enough.


On April 27, 2011, 3:30 a.m., Brad Kittenbrink wrote:
> > Finally, if we are only ever accessing the underlying memory directly (as 
> > seems to be the case here), why use a std::vector as buffer instead of an 
> > array?
> 
> Brad Kittenbrink wrote:
> I can't speak to the intent of the original author of this code, but I 
> always use vectors for dynamically sized arrays, as they automatically free 
> the buffer.  Using new[] or malloc is far more error prone, even when using 
> std::auto_ptr or boost::scoped_ptr for RAII.

Ah, right ... I keep forgetting that constant sized isn't enough for being 
statically sized.


- Boroondas


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/278/#review654
---


On April 26, 2011, 5:31 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/278/
> ---
> 
> (Updated April 26, 2011, 5:31 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fix for a minor buffer overrun on shutdown in LLVFS::audit.
> 
> 
> This addresses bug VWR-25608.
> http://jira.secondlife.com/browse/VWR-25608
> 
> 
> Diffs
> -
> 
>   indra/llvfs/llvfs.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/278/diff
> 
> 
> Testing
> ---
> 
> I tested using the Microsoft Debug Heap and confirmed that this allows the 
> Debug Heap to shut down without errors.
> 
> 
> Thanks,
> 
> Brad
> 
>

___
Policies 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-25608 error on shutdown due to buffer overrun in LLVFS::audit

[Boroondas Gupte]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/278/#review661
---

Ship it!


Ready to rock!

- Boroondas


On April 26, 2011, 5:31 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/278/
> ---
> 
> (Updated April 26, 2011, 5:31 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fix for a minor buffer overrun on shutdown in LLVFS::audit.
> 
> 
> This addresses bug VWR-25608.
> http://jira.secondlife.com/browse/VWR-25608
> 
> 
> Diffs
> -
> 
>   indra/llvfs/llvfs.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/278/diff
> 
> 
> Testing
> ---
> 
> I tested using the Microsoft Debug Heap and confirmed that this allows the 
> Debug Heap to shut down without errors.
> 
> 
> Thanks,
> 
> Brad
> 
>

___
Policies 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-25610 LLControlGroup::loadFromFile makes unnecessary copies of large LLSD objects

[Monty Brandenberg]

On 4/27/2011 2:57 PM, Brad Kittenbrink wrote:
> On April 27th, 2011, 4:16 a.m., *Boroondas Gupte* wrote:

> 2) Remove space between"const"  and"&", so that it's easer to 
> visually distinguish from binary operator&
> 2) I think this is a bad idea, that would be far less readable imho.

love brad for correct coding style.
___
Policies 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] OpenID based logins?

[Dave Booth]

DO NOT WANT.

My OpenID is linked to several RL sites that I want to have nothing to 
do with my SL. OpenID has already been pre-empted by 1L or RL  links. If 
it were 100% opt-in and guaranteed to never ever link to SL without 
explicit consent I'd support it because I know theres SLers out there 
that merge their identities that way and why shouldnt they? However, I 
have zero confidence that any SL implementation of openID  would meet 
those criteria.


On 4/21/2011 2:52 PM, Brandon Husbands wrote:
> Any thoughts to being able to link your SL account to an open id
> identity server?
>
> --
> ---
> This email is a private and confidential communication. Any use of email
> may be subject to the laws and regulations of the United States. You may
> not Repost, Distribute nor reproduce any content of this message.
> ---
> ---
>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

___
Policies 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] OpenID based logins?

[Kadah]

How about fixing the openID issues with jira before that? I would like
to be able to keep issues open within my browser without openID reseting
every tab the dashboard and forcing their history's to the openID
process page.
Monty and Oz said this was a known issue.

And I'm also against linking SL accounts with any other service. I feel
that should be opt-in only and done in a manner that will not risk
inadvertent disclosures of SL idents (like usernames) to these 3rd parties.


On 4/21/2011 4:34 PM, Yoz Grahame wrote:
> We've long thought about something like this, but it's currently low on
> the priority list.
> 
> For it to be really useful, it needs to work for viewer login; however,
> *that* needs web-triggered viewer login (as in, your authentication
> happens in an external browser window first, and then the viewer logs
> you straight in) otherwise you're forced to auth with your OpenID OP in
> the viewer window, and that's the classic Password Anti-Pattern*.
> 
> Also, *if* we ever do this, we'd probably target Google and Facebook
> login first, though I *think* that Google Auth uses OpenID so we might
> get everything in one shot. (There's a multiple-orders-of-magnitude
> difference between those who'd use Google/Facebook auth and those who
> even know what OpenID is)
> 
> In principle, I know of no reason why we wouldn't want this. We use
> OpenID and OAuth in various places already, and anything that makes it
> easier for people to authenticate securely is a Good Thing. However, we
> need to be convinced that there are major wins here before it can pushed
> up in the priorities.
> 
> *
> http://www.designingsocialinterfaces.com/patterns/The_Password_Anti-Pattern
> 
> On 21 April 2011 22:52, Brandon Husbands  > wrote:
> 
> Any thoughts to being able to link your SL account to an open id
> identity server?
> 
> -- 
> 
> ---
> This email is a private and confidential communication. Any use of
> email may be subject to the laws and regulations of the United
> States. You may not Repost, Distribute nor reproduce any content of
> this message.
> 
> ---
> 
> ---
> 
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
> 
> 
> 
> 
> ___
> Policies 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] Request for comment on these JIRA reports (Opensource Obscure)

[Hitomi Tiponi]

It was good to see some quick responses to the queries made by OO.

With so much work on Viewer 2 now being carried out by teams other than 
Snowstorm would it be possible to produce a list of tasks being carried out?  
Clearly if you are planning a 'wow' feature you may want to omit that, but it 
would be useful, and give us a warm feeling inside, if a list of JIRAs and 
other 
fixes/improvements that you are working on could be provided in some form.
___
Policies 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] OpenID based logins?

[Yoz Grahame]

On 28 April 2011 01:34, Kadah  wrote:

> How about fixing the openID issues with jira before that? I would like
> to be able to keep issues open within my browser without openID reseting
> every tab the dashboard and forcing their history's to the openID
> process page.
> Monty and Oz said this was a known issue.
>

I don't know which issue you're talking about from your description - is
there an existing issue you can point me to?
The main JIRA-related OpenID issue I'd love to fix is related to timeouts
and sign-out. There is currently no "single-sign-out" in the OpenID spec,
which means that until we can implement a uniform method of doing this
across RPs (which we have a plan for) we need to keep sessions fairly short,
and this is a right pain.


> And I'm also against linking SL accounts with any other service. I feel
> that should be opt-in only and done in a manner that will not risk
> inadvertent disclosures of SL idents (like usernames) to these 3rd parties.
>

I don't see how we could do it *without* it being opt-in. I mean, I'm sure
there are incredibly cunning ways that we could root those details out if we
were really determined, but not only do we not have the time, we're not
actually inclined that way to begin with.

Also, bear in mind that what we're talking about here is use of an OpenID
for private authentication, not for public display. This is not about doing
any kind of public association.

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

[opensource-dev] Fw: tornado hit my place

[Nicky Perian]

- Forwarded Message 
From: Nicky Perian 
To: molliescarbri...@yahoo.com; Imprudence Dev List 

Sent: Wed, April 27, 2011 8:22:15 PM
Subject: tornado hit my place


will be off lists and irc for next week or so.
___
Policies 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] OpenID based logins?

[Kadah]

On 4/27/2011 5:25 PM, Yoz Grahame wrote:
> 
> On 28 April 2011 01:34, Kadah  > wrote:
> 
> How about fixing the openID issues with jira before that? I would like
> to be able to keep issues open within my browser without openID reseting
> every tab the dashboard and forcing their history's to the openID
> process page.
> Monty and Oz said this was a known issue.
> 
> 
> I don't know which issue you're talking about from your description - is
> there an existing issue you can point me to?
> The main JIRA-related OpenID issue I'd love to fix is related to
> timeouts and sign-out. There is currently no "single-sign-out" in the
> OpenID spec, which means that until we can implement a uniform method of
> doing this across RPs (which we have a plan for) we need to keep
> sessions fairly short, and this is a right pain.

I described it to Oz and Monty and they knew almost instantly what I was
talking about so here's how is described it to them.
I'll have many open tabs on Firefox to jira issues, if I close and
resume the session, all those tabs will load, hit the openID auth and
all those tabs be redirected to the dashbord or to an a random issue
that I filed but wasn't opened in the previous session. 'Back' on the
tabs will only go back to the openID auth.
They said it was a known issue and from the reaction, it sounded like
there was already an open issue on this but either didn't know the key
or was an internal one. I'm unable to find a public one.
Maybe Oz know's more?

> And I'm also against linking SL accounts with any other service. I feel
> that should be opt-in only and done in a manner that will not risk
> inadvertent disclosures of SL idents (like usernames) to these 3rd
> parties.
> 
> 
> I don't see how we could do it *without* it being opt-in. I mean, I'm
> sure there are incredibly cunning ways that we could root those details
> out if we were really determined, but not only do we not have the time,
> we're not actually inclined that way to begin with.
> 
> Also, bear in mind that what we're talking about here is use of an
> OpenID for private authentication, not for public display. This is not
> about doing any kind of public association.
> 
> -- Yoz
>  
Its hard enough to get google to let me use 4 different accounts (all
for different things and one solely for apps) as is :P
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges