Second Life Wiki - User contributions [en]

Project Motivation

2007-11-20T15:59:04Z

Gibson Willis: /* Additional scaling factors */

{{Template:AWG_NavBox}}

According to Zero Linden, the project was motivated by thoughts a year ago when Second Life was growing rapidly and Linden Lab was thinking about how to scale the grid.

There have been two timeframes set back then: The next few months and the next years. This architecture discussion is about the next years.

== Scary numbers ==

If we assume that virtual worlds will be a significant part of the future, then the following numbers along the 4 population-related dimensions of scalability might not be so far off:

#Scalability of world extent:
#:* 60 million regions (probably more) (60 was mentioned [http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2007_Sep_18 here] by Zero Linden )
#Scalability of world population:
#:* 2 billion users
#Scalability of concurrent users:
#:* 50 - 100 million concurrency (on whatever device)
#Scalability for events (concurrent users in a single region):
#:* <strike>20 thousand</strike> per region ([[Event_Scalability_VAG|the raw population-based figures are currently being revised to include other factors]])

These are the primary numbers that drive the need for a scalable architecture. In Zero's view, these numbers will almost certainly happen, no matter what form virtual worlds take. These numbers will not be possible with the grid right now and additionally some more use cases need to be solved like connecting 3rd party hosted regions to the grid.

== Additional scaling factors ==

The above ''scary numbers'' stem from population pressure alone, but there are other areas of growth which compound the impact of those numbers still further. We might, or might not, take such numbers as guidelines that the architecture we devise should support. While we would like the architecture to support as many possible feature sets, and implementation strategies as possible, various numbers may or may not be achievable in any particular platform, but remain relevant anyway in a distributed platform that includes 3rd parties.

:* The number of online users wishing to attend a single event increases with the population. By simple proportionality:
:** from total population growth, 100 people today rises to ([[Scalability_VAG|20,000 per event]]) (this is arithmetic, not opinion)
:** from concurrent population growth, 100 people today rises to ([[Scalability_VAG|100,000 per event]]) (this is arithmetic, not opinion)
:::* ''(These are end-limit figures derived by simple proportionality and should not be considered use cases.)''
:* Media-led scenarios ("Observer Mode") remove all client-side scaling barriers to allowing [[Use_Cases#SecondlifeTube|millions of event observers]].
:* Prim count expectations grow naturally. Limiting them to current values is not tenable.
:* Scripting load will grow roughly in proportion to prim numbers, as well as proportional to population through attachments.
:* Current growth is tiny compared to what will happen when TV-led events like [http://www.nytimes.com/2007/10/04/arts/television/04CSI.html CSI:NY/SL] turn SL mainstream. Concurrent usage pressure will explode.

There also are numbers that are ''not'' expected to grow but still may have a significant impact on technical decisions regarding architecture, so they may be used to "anchor" anticipations and as a base for designing the rest of the architecture. These are the expected end-user capacities:
:* The maximum number of concurrent interactions with other people per player is not expected to increase. There are only so many people we can consider and be attentive to simultaneously, that making more people visible or heard makes no useful difference or even degrades experience.
:* The maximum chatting output per player isn't growing anytime soon either.
:* The maximum number of concurrent world interactions is pretty fixed: there are only so many prims we can modify, scripts we can interact with, objects we can manipulate simultaneously ; and we can only manage to maneuver so fast, that flying, driving and taking sharp turns faster is impractical.
:* The update frequency required to simulate smooth movement or make a curved, arbitrary trajectory not appear disjointed or jerky is not going to increase over a few dozen Hz, and there are only so many moving objects we can be attentive to and in whose movement we can detect discrepancies.

[[Category: AW Groupies]]

User:Zero Linden/Office Hours/vote

2007-11-20T15:22:35Z

Gibson Willis:

I have to change the Thursday office hour time. There are to options:
* Move it to Wednesday, still at 7:30 AM -- '''votes:''' 2
* Keep it on Thursday, but move to 8:30 AM -- '''votes:''' 0

Vote by increasing the number on one of those lines by one.

Thanks, Zero

Viewer Authentication Critique

2007-11-01T14:19:20Z

Gibson Willis: /* Summary */

This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.

For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]

== Note ==

It was not explicit in the original article what the motivations behind LL's proposed new authentication system are. The goals (Security, Flexibility, Persistence) and benefits listed here are what SLDev believed them to be based on the original description and e-mail discussions. One of the less stated but said higher priority goals[https://lists.secondlife.com/pipermail/sldev/2007-October/005546.html] is that of anti-fraud measures, but it is not practical to critique unpublicized or miscommunicated anti-fraud plans. This article, therefore, still lacks an essential critique about fraud prevention/detection as possibly desired when solicited.

== Summary ==

There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks in that it would acclimatise users to starting the viewer via a web page. At present most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords, due to security compromises in the LL websites or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).

Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.

There seems to be no real demand to synchronize the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions. A relatively simpler mod to the web site could prevent the account details for a different alt displaying when the account menu options are selected in the client. There is an argument that separating the passwords and logon for the forums would actually improve security.

The suggestion of providing an embedded way of displaying the web form within the viewer so that you will not have to always start the viewer from a web browser is a non-starter, not just because of problems with the current code in handling web proxies, but because it would be very easy for the embedded web form handling code to log the form data before POSTing to the web site thus undermining any benefits gained.

Overall, the additional development time both for LL and for external developers doesn't seem to warrant the promoted benefits.

It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.

== Security ==

=== Benefits Stated By LL ===
* To mitigate the danger of password capturing Trojans masquerading as third party viewers
* Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.
* To consolidate the authentication implementation in order to support back-end anti-fraud work

=== Pros ===
* Viewer does not have to process (and "see") username and password

=== Cons ===
* The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.
** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).
** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.
* But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.
 
* Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!
** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.
*** This kind of attack is not theoretical, phishing websites are a criminal industry.
*** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer
** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns
** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)
* So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.
 
* And the mechanism itself is relatively inflexible.
** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program
** Links to secondlife:// can not pass parameters to the program
*** In fact allowing that was a security flaw recently found and fixed in the SL client. :(
** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid
 
* It is suggested that the viewer will embed the web form within the viewer -
** This escalates the importance of addressing a number of current problems with llmozlib in the current viewer code:
*** there are problems compiling llmozlib on the Linux platform
*** proxies are not supported
** In any case, a modded client easily log the form data before submitting it to the webform, i.e. all the concerns about clients grabbing passwords would still apply!
 
* Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)
** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.

=== Alternatives ===
* One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)
* lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)
* separate passwords for website account and being inworld
* Account restrictions
* Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)
* For considation have a single backend web service which does the actual authentication - but which is fronted by GUI frontends (e.g. in the viewer) and web frontends (e.g. for accessing the web based account pages etc.)
* Do nothing, keep everything as it is.
** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers
** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises
 
* Log of successful or failed login attempts including ip address (or at least a notice of the last attempt)
* Black, White or Greylist IP (specific or > network ranges)- This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. > IP's on the blacklist would not be able to log into the account at all
** Question: how many people have, or even know they have, static or semi static IPs?
* Lock account if too many consecutive logon requests (to prevent automated dictionary attacks) - a user should be able to unlock an account via the website using additional validation such as CAPTCHA's and providing additional information on file such as date of birth.
 
* This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.
** CRAM-MD5 or a similar challenge-response type
*** Note that the proposed authentication mechanism via a web form might prevent any attempt at implementing a challenge-response mechanism
** Dictionary check to reject insecure passwords

== Flexibility ==

=== Benefits Stated By LL ===
* Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems
* Extension of this to allow non-LL applications and web sites to participate in this single sign on system.

=== Pros ===
* Enables username/password authentication to work on third party sites without them having to "see" username and password

=== Cons ===
* This is really an unrelated issue...
** The client doesn't need to depend on the website for this purpose, or this could be a command line option.
** The client could just as easily be the 'authentication source' as the website.
*** Via a "go to website" link in the client that passed an equivalent token.
 
* As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes

=== Alternatives ===
* Use this mechanism for websites (including third party) only but not for viewers
 
* Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]
** OpenID - [http://openid.net/]
** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]
** Shibboleth - [http://shibboleth.internet2.edu/]
** CAS - [http://www.ja-sig.org/products/cas/]
*** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security

== Persistence ==

=== Benefits Stated By LL ===
* To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.

=== Pros ===
* Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different

=== Cons ===
* As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.
* Inconvenient for those with alts or multiple clients
** Cumbersome to change alts and logon with multiple alts
** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL
** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes
* Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.
* Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld
* starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.
* this would have an impact on the architecture discussions for a future open grid.

=== Alternatives ===
* As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).
* Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".
* There is an argument that the forum logon should be seperated from the SL account logon
** This would fit the practice of those using alts, when they only use one account on the forums but would need to check the account details of various alts.
** Having seperate passwords would isolate security compromises in the forums software from compromising the SL account itself.

== Signatories ==

Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with.

* [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)
* [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)
* [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)
* [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)
* [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)
* [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)
* [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)
* [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)
* [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)
* [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT) (Please see my notes: [https://lists.secondlife.com/pipermail/sldev/2007-October/005605.html] [https://lists.secondlife.com/pipermail/sldev/2007-October/005615.html])
* [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)
* [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)
* [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)
* [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)
* [[User:Jabath Steuart|Jabath Steuart]] 04:03, 1 October 2007 (PDT)
* [[User:Nik Woodget|Nik Woodget]] 05:19, 1 October 2007 (PDT)
* [[User:Whoops Babii|Whoops Babii]] 05:29, 1 October 2007 (PDT)
* [[User:Feep Larsson|Feep Larsson]] 06:29, 1 October 2007 (PDT)
* [[User:Gibson Willis|Gibson Willis]] 07:11, 1 October 2007 (PDT)
* [[User:Grazer Kline|Grazer Kline]] 10:34, 1 October 2007 (PDT)
* [[User:Odysseus Fairymeadow|Odysseus Fairymeadow]] 13:58, 1 October 2007 (PDT)
* [[User:Melanie Milland|Melanie Milland]] 16:23, 2 October 2007 (PDT)
* [[User:Seg Baphomet|Seg Baphomet]] 09:33, 8 October 2007 (PDT)

Viewer Authentication Critique

2007-10-01T14:11:47Z

Gibson Willis: /* Signatories */

This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.

For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]

== Summary ==

The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem.

There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).

Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.

There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions.

Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.

It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.

== Security ==

=== LL's Objectives ===
* To mitigate the danger of password capturing Trojans masquerading as third party viewers
* Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.

=== Pros ===
* Viewer does not have to process (and "see") username and password

=== Cons ===
* The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.
** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).
** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.
* But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.
 
* Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!
** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.
*** This kind of attack is not theoretical, phishing websites are a criminal industry.
*** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer
** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns
** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)
* So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.
 
* And the mechanism itself is relatively inflexible.
** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program
** Links to secondlife:// can not pass parameters to the program
*** In fact allowing that was a security flaw recently found and fixed in the SL client. :(
** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.
 
* Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)
** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.

=== Alternatives ===
* One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)
* lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)
* separate passwords for website account and being inworld
* Account restrictions
* Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)
* Do nothing, keep everything as it is.
** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers
** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises
 
* This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.
** CRAM-MD5 or a similar challenge-response type
** Dictionary check to reject insecure passwords

== Flexibility ==

=== LL's Objectives ===
* Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems
* Extension of this to allow non-LL applications and web sites to participate in this single sign on system.

=== Pros ===
* Enables username/password authentication to work on third party sites without them having to "see" username and password

=== Cons ===
* This is really an unrelated issue...
** The client doesn't need to depend on the website for this purpose, or this could be a command line option.
** The client could just as easily be the 'authentication source' as the website.
*** Via a "go to website" link in the client that passed an equivalent token.
 
* As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes

=== Alternatives ===
* Use this mechanism for websites (including third party) only but not for viewers
 
* Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]
** OpenID - [http://openid.net/]
** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]
** Shibboleth - [http://shibboleth.internet2.edu/]
** CAS - [http://www.ja-sig.org/products/cas/]
*** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security

== Persistence ==

=== LL's Objectives ===
* To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.

=== Pros ===
* Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different

=== Cons ===
* As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.
* Inconvenient for those with alts or multiple clients
** Cumbersome to change alts and logon with multiple alts
** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL
** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes
* Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.
* Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld
* starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.
* this would have an impact on the architecture discussions for a future open grid.

=== Alternatives ===
* As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).
* Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".

== Signatories ==

Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with.

* [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)
* [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)
* [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)
* [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)
* [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)
* [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)
* [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)
* [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)
* [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)
* [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT)
* [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)
* [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)
* [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)
* [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)
* [[User:Jabath Steuart|Jabath Steuart]] 04:03, 1 October 2007 (PDT)
* [[User:Nik Woodget|Nik Woodget]] 05:19, 1 October 2007 (PDT)
* [[User:Whoops Babii|Whoops Babii]] 05:29, 1 October 2007 (PDT)
* [[User:Feep Larsson|Feep Larsson]] 06:29, 1 October 2007 (PDT)
* [[User:Gibson Willis|Gibson Willis]] 07:11, 1 October 2007 (PDT)

Talk:Channel and Version Requirements

2007-09-28T19:12:46Z

Gibson Willis:

{{Talk}}

== Adding a fifth number to versions ==

I think this all makes sense except for this part:

Choose a version number
* The version number is in the form Major.Minor.Patch.Build
* The version number can be any four numbers
* We recommend using the Major, Minor, and Patch numbers from the most recently merged Linden Lab source code.
* We recommend using a Build number >= 100 to indicate a non Linden Lab version.

I think that the versions should be 5 numbers, since there have been occasions where multiple versions of Major.Minor.Patch have been released by Linden Lab. For example (from [[Source_downloads]]):

* ver 1.18.2.1
* ver 1.18.2.0

* ver 1.14.0.1
* ver 1.14.0.0

So, my proposal would be that the number be in the form Major.Minor.Patch.Build.3rdPartyNumber. [[User:Gibson Willis|Gibson Willis]] 12:12, 28 September 2007 (PDT)

Talk:Channel and Version Requirements

2007-09-28T18:21:35Z

Gibson Willis:

I think this all makes sense except for this part:

Choose a version number
* The version number is in the form Major.Minor.Patch.Build
* The version number can be any four numbers
* We recommend using the Major, Minor, and Patch numbers from the most recently merged Linden Lab source code.
* We recommend using a Build number >= 100 to indicate a non Linden Lab version.

I think that the versions should be 5 numbers, since there have been occasions where multiple versions of Major.Minor.Patch have been released by Linden Lab. For example (from [[Source_downloads]]):

* ver 1.18.2.1
* ver 1.18.2.0

* ver 1.14.0.1
* ver 1.14.0.0

So, my proposal would be that the number be in the form Major.Minor.Patch.Build.3rdPartyNumber.

Talk:Channel and Version Requirements

2007-09-28T18:02:37Z

Gibson Willis: New page: I think this all makes sense except for this part: Choose a version number * The version number is in the form Major.Minor.Patch.Build * The version number can be any four number...

I think this all makes sense except for this part:

Choose a version number
* The version number is in the form Major.Minor.Patch.Build
* The version number can be any four numbers
* We recommend using the Major, Minor, and Patch numbers from the most recently merged Linden Lab source code.
* We recommend using a Build number >= 100 to indicate a non Linden Lab version.

I think that the build numbers should be 5 numbers, since there have been occasions where multiple versions of Major.Minor.Patch have been released by Linden Lab. For example (from [[Source_downloads]]):

* ver 1.18.2.1
* ver 1.18.2.0

* ver 1.14.0.1
* ver 1.14.0.0

So, my proposal would be that the number be in the form Major.Minor.Patch.Build.3rdPartyNumber.

Searching FAQ

2007-09-05T00:38:28Z

Gibson Willis: /* Use product-exchange sites. */

=== Disclaimer ===
* This article is my opinion. It is not necessarily backed by Linden Labs or anyone else.
* I welcome feedback on the article, and am especially keen on constructive suggestions. I will however ignore flames, trolling, personal attacks, etc.
* This article is intended to be very helpful, useful, insightful and generally good, however it is offered 'as is' and I do not guarantee that it is any of these.
* The original version of this FAQ was written by Angel Fluffy, but has probably been edited/changed since then. If you edit this page a lot, please remove the "Angel Fluffy's" from the title, to make it clear the page is a community effort.

=== Angel Fluffy's Searching / Finding Products FAQ ===
This page is intended to help answer the age old-question of "how do I find the product I want in SL?".

Put bluntly, there are 3 main ways of finding the items you want :
# Look in-world.
# Look at websites about SL products.
# Ask others for help.

I'll cover each below.

==== Look in-world.====

===== Use the Search tool =====
In the SL client, you have a "Search" button at the bottom of your screen.
This search button should be your first port of call when attempting to find anything in Second Life.
The two most important things about using the search tool are searching under the right window, and using the right search terms.
In general, start out as specific as possible, and gradually become more general in your searches if you do not find what you are looking for.
====== Searching the right tab ======
Most obvious searches have their own tab, for example, if you're searching for a person, use the "people" tab.
However, some searches use multiple tabs. For example, if you are searching for clothes, you should probably use both the "places" (stores will have 'clothes' as a keyword) and also the 'classifieds' tab (stores will advertise there).
In general, if you don't find what you're looking for under the tab you expect, try other tabs. Use the "All" tab last, for it can return a LOT of irrelevant results.
====== Using the right search terms ======
Identify the few words that best describe what you are looking for. Avoid using common, or irrelevant words, such as 'the', 'a', 'and', 'it', 'will', or 'does'. Use only keywords that summarise what the object is or what it does. Good keywords for objects describe the thing you want as much as possible in the shortest time, and are specific. For example, 'tuna' is better than 'fish', 'suit' is better than 'clothes', 'rental' is better than 'property' and 'panther' is better than 'cat'.
Start with the most specific keywords you can think of, and broaden out if a search on those doesn't find what you're looking for. For example, if you're searching for a an object that looks like a tuna fish, search for 'tuna', then 'fish', then 'animals', becoming more general each time you don't find what you're looking for.

===== Ask vendors who make similar things. =====
If you can find someone who makes something very close to what you want, check if they do custom work, by looking around their main store, and checking *all* the areas of their profile.
If they make something similar to what you want, and their store/profile doesn't clearly say that they don't do custom work, it may be worth asking them if they would do a custom version of their product, just for you, to get it exactly how you want it.
Be warned, most product makers will charge for this - and the bigger the changes you want made, the more they will charge.
Rates for custom work are sometimes negotiable. If the price you are quoted for custom work seems too high, say so, and offer what you think is a more reasonable price.
If they won't do custom work, or they would charge too much for doing it, or it simply can't be done, then try asking someone else who makes products similar to what you want.
Never hold it against a creator that they won't do custom work for you. Often creators are both creators and business owners, and this makes them very busy. Just like you, they want to enjoy their Second Life, and custom work takes a lot of time. Many of them therefore choose to not do any custom work on their products, even if you are prepared to offer them money for doing it.
Don't be offended if they say no - it is almost never personal - they're usually just too busy.

===== Ask your friends. =====
Make sure to ask those friends of yours who may also be interested in the same thing. For example, if you like to parachute in SL, and you want to find a prim parachute, then it makes sense to ask your friends who also like parachuting where parachutes can be found.

===== Ask the community leaders. =====
These people can be identified as they've been in SL a long time and tend to own or run the popular locations or groups for people with that interest. For example, if you were looking for a copy of Cloud's Ultima Sword (an item from a Final Fantasy video game) you might go to FF fan clubs and ask the people who seem to know the most about FF.

Similarly, if you were looking for a good set of lights for your house, you might want to ask someone who advertises as a builder or interior designer. Find the places associated with FF, using the above search techniques, then find the people who own/run those places, and (if they don't mind) ask them.

==== Use product-exchange sites. ====

Go to sites like [http://www.slexchange.com SLExchange] and [http://shop.onrez.com Shop OnRez] - and search them, too, looking for items with the keywords you picked out above. Sites like this are a quick way to search through a lot of different products and zero in on the ones you want, without having to spend time teleporting from store to store... or time wandering around stores looking for where the product you want is sold.
Be warned, however, that many content creators (including myself) sometimes refuse to list things for sale on SLX and similar sites, due to their high listing fees. There are many vendors who can only be found inside Second Life, and if you use SLX/etc instead of searching in-world you will miss out on these. SLX and similar sites are good places to look if you want to browse products on the web, but they cannot replace in-world searching.

==== When to post in [http://forums.secondlife.com/forumdisplay.php?f=147 the SL new products forum]. ====

If you can't find it in-world using the above methods, then your best option may be to post to this forum. There are other similar forums, such as the one at [http://www.secondcitizen.com Second Citizen], however these tend to have even lower traffic than the main forum, so they should probably be the last place you look.

Before you post to any forum, asking where you can find something, you should make sure that :

===== You have already looked in-world. =====
Looking in-world is faster than posting to this forum, and more effective in most cases.
Be sure to look in-world first, and when you post, say that you have already looked in-world. Saying that makes it more likely others will help you.

===== You know what you want. =====
Quite simply, if you don't understand what you want, you will have a hard time finding it.
Make sure you know what you want BEFORE you post here.
The process of looking at existing products often helps you figure out what you want. If in doubt, try some of the existing products similar to what you think you want, and then build up a list of ways you think they could be improved. Use the description of that product and the list of ways it could be improved, to come up with a description of the product you really want.
If you come up with a list of suggested improvements for a product, try sending that list to the product's creator, so they can improve their product. The creator might be inspired to improve his product, or might tell you where you can get a product which is more like what you want.

===== You can describe what you want clearly. =====
For anything you want, you should describe as much as possible of its appearance, its function and purpose.
Describing its appearance is necessary because otherwise you may end up with a lot of objects which you don't like the look of. Describing its function is necessary because otherwise you may well end up with an object that doesn't work, or doesn't do the thing you want it to do. Describing its purpose is also a good idea, because by describing its purpose you help people understand *why* you want the object, and thus, both potentially gather support from other consumers.
If other people understand why you want the object, they may see the need the object addresses, and thus may want the object too. If they also want the object, you can group together and try to get someone to make it for you - both spreading the costs if making the object takes custom work, and also being more likely to get the attention of creators by showing that demand for the object is there.
Telling people why you want the object is also a good idea because then they can suggest new features or changes to the object that would make it better at its purpose. For example, if you say you want a light for your home, with an on/off switch, people may suggest places where you can buy these lights. If on the other hand you say that *and* you say that you want this on/off switch so that the light can be turned off when nobody is around, then someone may suggest that instead of having a light with an on/off switch, you consider a light that turns on when you touch it, and turns off automatically once you leave the area.
Thus, telling people *why* you want a certain product often enables them to see your problem, and thus propose better solutions to your problem. The net result is that you discover new and better ways of solving your problem - ways you might not have thought up yourself.
So, for these reasons, always give clear and accurate details on the appearance, function and purpose of products you request.

===== You know how it differs from what already exists. =====
If there is a well-known product that already exists which is similar to what you want, make sure that you mention this and explain the differences.
The reason for this is simple : it helps explain what you want clearly, and means people are less likely to just refer you back to that well-known product.

===== You have some idea of what you'd be willing to pay for it. =====
Often, different examples of the same basic idea can vary wildly in price. A simple glowing box 'light' for example, may be free and easy to make within about 10 seconds. A very complex prim 'light' with off/on commands, or which turns off/on automatically when people enter the room, for example, might cost a fair bit of money. The classic case of this is permissions : the more permissions the object comes with, the more it typically costs. Have a think about what you'd be willing to pay for the product. Some things cost a lot more than you'd expect.
To prevent yourself spending more than you can afford, I suggest having a budget, and avoiding spending money on non-essential things unless you have cash to spare. When you do come to buy non-essential things, you should still have a budget there too - aim to get value for money. Value for money does NOT mean buying the cheapest thing. Value for money means spending your money such that you get the most use out of it. Effectively, it means spending your money on the things which you'd enjoy most, the things you'd use most, the things which mean the most to you.
As with anything related to money, the best way to deal with it is by making a plan in advance, to make sure that if surprises come up that you're equipped to deal with them.

===== You are prepared to work with other people. =====
Put simply, this forum is based around the idea of Residents helping each other find things. So, you'll have more luck here if you're polite and tactful.
Avoid saying : "______ sucks! If I had made a ______, I would have done ______".
Instead, try saying : "______ does ______ well, but isn't so good at doing _____. I'd really like it to do _______. Can anyone please point me to a product that does _____?"
Bear in mind people replying to your posts on this forum are usually trying to help you. So, if you help them by being as clear and polite as possible, you greatly increase your chances of getting what you want.

Content Creation

2007-09-05T00:37:38Z

Gibson Willis: /* Homesteading */

One of the most unusual features of the Second Life Virtual World is that any user can create new stuff that every one else can see and use. The ambitious can create things for sale. The artistic can create art. Monopoly players can buy and sell land using real money and hotels. All of these things together are called ''Content Creation''.

One reason that people are willing to put their creations into Second Life is that SL tries hard to protect [[Intellectual Property Rights]] (or IP, for short). just like in the real world, there are ways to steal other peoples creations, but in SL this is for the most part not a common, recurring problem, thanks to the close attention given to it by the SL technology.

So, what does it mean to "Create Content"? This page is a high level overview, with pointers to more detailed information for content creators. It describes the broad categories of things that users of SL create, and what kinds of tools they use to create them. Enjoy. Remember, this is '''your''' Wiki. Feel free to edit it to your satisfaction.

==Homesteading==

Lots of SL residents buy a piece of virtual land, and start building a dream home. Maybe a fishing camp, or a ski lodge, or a beach house, or a mountain top castle with a dungeon. As the tag line says, it is your imagination.

There are lots of different approaches. Some people start out with the [[Building Tools#Bull Dozer|bulldozer]] tool in the [[Building Tools#Land Editor|Land Editor]], and grade their land the way they want it. Then they buy a prefabricated house at a place like [SLExchange.com] or [OnRez.com], or at one of the many in-world architect firms. With more money, one might have a house and landscaping done by a custom builder.

Is this sounding like the real world?

It is also common to garden, either buying or making [[Flora and Fauna]].

The in-world [[Building Tools|building tools]] can be used to make many of these things from scratch. Yes, it takes time and practice, but for some people it is very fulfilling to see blocks of raw materials slowly assembled into a luxury retreat.

The default building material at first looks like plywood. If you want a marble wall instead of a plywood wall, then what? The answer is to apply a [[Textures|texture]]. This is an image of what the surface should look like, applied over the plywood. Every resident has a [[Inventory Library|library]] of textures, and there are lots more available for free and for purchase. Textures are also a good example of building tools outside SL. To make a unique texture, use a tool such as [[Building Tools#2D Graphics|Adobe Photoshop or the GIMP]] to create an image that you later upload to be used in SL. Nice image? [[Commerce|Sell it!]]

One last thing about homesteading. Sometimes buildings, landscape, or flora and fauna do something. Doors open and close. Fireflies flicker. People sit in hot tubs. What these all have in common is that the actions are usually controlled by a [[Scripting in LSL| script]], which is a set of instructions in a language called Linden Scripting Langage, or LSL. Like everything else in SL, there are lots of scripts already available for free and for purchase, and if you like that kind of thing, you can do it yourself.

==Fashion==

It seems like people really love to shop in SL. Perhaps it is because things they cannot afford in real life are so inexpensive in SL.

People like cool hair, jewelry, clothes, shoes, and somebody has to make all that stuff. There is even a ''Cosmopolitan'' like [SL Fashion magazine].

Making all these things in SL varies from easy to difficult. Simple hair and clothes can be made with the [[Appearance Editor]]. Nicer things require more work.

===Clothing===
Nice clothing is usually a combination of objects made with the [[Building Tools|Object Editor]], and material made with an external [[Building Tools#2D Graphics|2D graphics]] program such as Photoshop or the GIMP. Artistic skill and determination required.

===Hair===
Hair is usually made using the [[Building Tools|Object Editor]]. It is built up lock by lock. It is colored using images created using 2D graphics.

===Jewelry===
Like hair, usually made in the [[Building Tools|Object Editor]] and then colored with images.

===Body Shape and Skin===

Surprise. In the real world, you are born with your body and skin, and stuck with it. In SL it is something you can make or buy. Think of skin as a sort of tight fitting piece of art with all the interesting bits painted on. Shape is made using the [[Appearance Editor]].

==Commerce==

Have you always wanted to run the coolest club in town? Apparently, you are not alone, since SL has cool clubs everywhere, with every possible imaginable theme.

*Buy or rent some land.
*Build or have built a club.
*Advertise.
*Hire a staff of DJs, musicians, sex workers, or whatever you think a cool club needs.

How about a clothing store? Or a travel agency, or a marina or a golf course or a ski lodge. Coffee house? Chess club?

Buy it, build it, and run it.

==Devices==

Building a house in SL is not that different from building a sail boat. They are both made of objects using the [[Building Tools#Object Editor|Object Editor]].

However, consider the difference between a door, an wall, and a sail boat. A wall doesn't usually do much. Once it is built, and has some wall paper, it pretty much just sits there. A door, on the other hand, has a behavior. It opens and closes. A fancy door might only open when the house owner approaches, or when someone utters the secret password ("friend", in case you ever need it).

To make a door do this kind of thing, it needs a [[LSL Portal|script]], a precise set of instructions written in LSL, the Linden Scripting Language.

Now consider a sail boat. The script in a sail boat is much more complex than the one in a door. It puts the sails up and down, it makes the boat heel over if the wind blows harder, it determines how fast the boat should go depending on the wind speed and direction. A simple sail boat script will do this in a half-assed sort of way, and a really good sail boat script will do this in a sophisticated and high priced sort of way.

Some people have created very elaborate devices that do all sorts of useful things. The furniture that contains dozens of animations that take over your avatar when you sit on them are a good example.

People also make things like umbrellas, parachutes, parrots, animation overriders, espionage devices, links to external web pages, fireworks, helicopters, flying carpets, torture devices, pleasure devices, pleasure devices for people who like to be tortured, pets that follow you around, ...

Get it? Visit the [[LSL Portal]] for more details.

==Activities==

==Development==

==Tool Building==

Skinning

2007-07-24T23:15:01Z

Gibson Willis: /* Improve Layout Language */

== Objectives ==
* Enable internal designers to more easily customize the look of Second Life
* Enable external developers and residents to save customizations and prepare skin "packages"
== Links ==
* [[User Interface Roadmap]]
== Task Descriptions ==
=== XUI Default Templates ===
JIRA: https://jira.secondlife.com/browse/VWR-1882
* ''Objective: Make the XUI files less verbose and more readable''
* Create 'templates.xml' file with default attributes for each widget type
** Other templates for common attribute sets can also be declared here
** Widgets can declare a tempate (default to the default one for that type)
* Remove all default values from the code (code cleanup)
* Create a tool to process all existing .xui files and write out only the non default values
** Clean up the XML output at the same time

=== UI Texture Cache ===
JIRA: https://jira.secondlife.com/browse/VWR-1883
* ''Objective: Make it easier to add and modify UI art''
* Separate pre-cached images with asset ids from UI images
* Rename UI Images to use file names not asset ids

=== Remove hard coded art and colors from UI ===
JIRA: https://jira.secondlife.com/browse/VWR-1884
* ''Objective: Remove any UI art from the code
* Remove programmatic art with attributes, e.g. volume sliders
* Remove any backgrounds from icons, etc (use alpha)
* Ensure that all images can be cropped and scaled
* Allow specification of fixed size borders (i.e. so that button graphics with narrow boarders scale correctly)
* Enable additional attributes to widgets for colors, etc

=== Facilitate UI customization ===
JIRA: https://jira.secondlife.com/browse/VWR-1885
* ''Objective: Make it easier to see the effects of XUI edits''
* Enable reloading of all floaters including the menus and overlay bar
* Ensure all floaters can handle missing UI elements and will behave reasonably or refuse to open with an appropriate message

=== Facilitate customization of menus and overlay bar ===
JIRA: https://jira.secondlife.com/browse/VWR-1886
* ''Objective: enable menus and overlay bar to be more easily customized''
* Create a global floater/panel map and have floaters/panels to specify their type (e.g. "floater_inventory" -> LLFloaterInventory) in XML
* Allow buttons to open floaters by name
** Include support for opening a specific tab
** Differentiate between toggling state of singletons, showing/focusing, and opening new instances
* Allow menus to be expanded/collapsed for simple/advanced usage
* Specify layout of overlay bar and menu bar in "viewer.xml"
** Allow multiple "overlay bars" to be added so that side bars or corner panels with buttons can be added

=== Improve Layout Language ===
JIRA: https://jira.secondlife.com/browse/VWR-1887
* ''Objective: make it easier to change the XUI layout data''
* Choose a standard model for the layout language (e.g. CSS? qt-like?)
* Allow elements to be grouped for layout purposes
* Auto layout elements when no layout information is provided

=== Enable Packaging and Resident customizations ===
JIRA: https://jira.secondlife.com/browse/VWR-1875
* ''Objective: enable external developers and residents to preserve changes across updates and distribute custom UI layouts''
* Allow residents to save changes to a user local directory (i.e. Documents and Settings\User\Application Data\SecondLife\skins)
* Allow residents to package changes and easily distribute them for easy installation by other users
** Define location to search for installed skin packages
** Include the ability to change skins and restore the original skin
=== Specific Requests ===
* Make iconic panels (i.e.. build tools) generally available
** Combination of fully iconic buttons and the ability for a button to open a specific tab in a floater

Skinning

2007-07-24T23:12:05Z

Gibson Willis: /* Facilitate customization of menus and overlay bar */

== Objectives ==
* Enable internal designers to more easily customize the look of Second Life
* Enable external developers and residents to save customizations and prepare skin "packages"
== Links ==
* [[User Interface Roadmap]]
== Task Descriptions ==
=== XUI Default Templates ===
JIRA: https://jira.secondlife.com/browse/VWR-1882
* ''Objective: Make the XUI files less verbose and more readable''
* Create 'templates.xml' file with default attributes for each widget type
** Other templates for common attribute sets can also be declared here
** Widgets can declare a tempate (default to the default one for that type)
* Remove all default values from the code (code cleanup)
* Create a tool to process all existing .xui files and write out only the non default values
** Clean up the XML output at the same time

=== UI Texture Cache ===
JIRA: https://jira.secondlife.com/browse/VWR-1883
* ''Objective: Make it easier to add and modify UI art''
* Separate pre-cached images with asset ids from UI images
* Rename UI Images to use file names not asset ids

=== Remove hard coded art and colors from UI ===
JIRA: https://jira.secondlife.com/browse/VWR-1884
* ''Objective: Remove any UI art from the code
* Remove programmatic art with attributes, e.g. volume sliders
* Remove any backgrounds from icons, etc (use alpha)
* Ensure that all images can be cropped and scaled
* Allow specification of fixed size borders (i.e. so that button graphics with narrow boarders scale correctly)
* Enable additional attributes to widgets for colors, etc

=== Facilitate UI customization ===
JIRA: https://jira.secondlife.com/browse/VWR-1885
* ''Objective: Make it easier to see the effects of XUI edits''
* Enable reloading of all floaters including the menus and overlay bar
* Ensure all floaters can handle missing UI elements and will behave reasonably or refuse to open with an appropriate message

=== Facilitate customization of menus and overlay bar ===
JIRA: https://jira.secondlife.com/browse/VWR-1886
* ''Objective: enable menus and overlay bar to be more easily customized''
* Create a global floater/panel map and have floaters/panels to specify their type (e.g. "floater_inventory" -> LLFloaterInventory) in XML
* Allow buttons to open floaters by name
** Include support for opening a specific tab
** Differentiate between toggling state of singletons, showing/focusing, and opening new instances
* Allow menus to be expanded/collapsed for simple/advanced usage
* Specify layout of overlay bar and menu bar in "viewer.xml"
** Allow multiple "overlay bars" to be added so that side bars or corner panels with buttons can be added

=== Improve Layout Language ===
* ''Objective: make it easier to change the XUI layout data''
* Choose a standard model for the layout language (e.g. CSS? qt-like?)
* Allow elements to be grouped for layout purposes
* Auto layout elements when no layout information is provided
=== Enable Packaging and Resident customizations ===
JIRA: https://jira.secondlife.com/browse/VWR-1875
* ''Objective: enable external developers and residents to preserve changes across updates and distribute custom UI layouts''
* Allow residents to save changes to a user local directory (i.e. Documents and Settings\User\Application Data\SecondLife\skins)
* Allow residents to package changes and easily distribute them for easy installation by other users
** Define location to search for installed skin packages
** Include the ability to change skins and restore the original skin
=== Specific Requests ===
* Make iconic panels (i.e.. build tools) generally available
** Combination of fully iconic buttons and the ability for a button to open a specific tab in a floater

Skinning

2007-07-24T22:59:15Z

Gibson Willis: /* Facilitate UI customization */

== Objectives ==
* Enable internal designers to more easily customize the look of Second Life
* Enable external developers and residents to save customizations and prepare skin "packages"
== Links ==
* [[User Interface Roadmap]]
== Task Descriptions ==
=== XUI Default Templates ===
JIRA: https://jira.secondlife.com/browse/VWR-1882
* ''Objective: Make the XUI files less verbose and more readable''
* Create 'templates.xml' file with default attributes for each widget type
** Other templates for common attribute sets can also be declared here
** Widgets can declare a tempate (default to the default one for that type)
* Remove all default values from the code (code cleanup)
* Create a tool to process all existing .xui files and write out only the non default values
** Clean up the XML output at the same time

=== UI Texture Cache ===
JIRA: https://jira.secondlife.com/browse/VWR-1883
* ''Objective: Make it easier to add and modify UI art''
* Separate pre-cached images with asset ids from UI images
* Rename UI Images to use file names not asset ids

=== Remove hard coded art and colors from UI ===
JIRA: https://jira.secondlife.com/browse/VWR-1884
* ''Objective: Remove any UI art from the code
* Remove programmatic art with attributes, e.g. volume sliders
* Remove any backgrounds from icons, etc (use alpha)
* Ensure that all images can be cropped and scaled
* Allow specification of fixed size borders (i.e. so that button graphics with narrow boarders scale correctly)
* Enable additional attributes to widgets for colors, etc

=== Facilitate UI customization ===
JIRA: https://jira.secondlife.com/browse/VWR-1885
* ''Objective: Make it easier to see the effects of XUI edits''
* Enable reloading of all floaters including the menus and overlay bar
* Ensure all floaters can handle missing UI elements and will behave reasonably or refuse to open with an appropriate message

=== Facilitate customization of menus and overlay bar ===
* ''Objective: enable menus and overlay bar to be more easily customized''
* Create a global floater/panel map and have floaters/panels to specify their type (e.g. "floater_inventory" -> LLFloaterInventory) in XML
* Allow buttons to open floaters by name
** Include support for opening a specific tab
** Differentiate between toggling state of singletons, showing/focusing, and opening new instances
* Allow menus to be expanded/collapsed for simple/advanced usage
* Specify layout of overlay bar and menu bar in "viewer.xml"
** Allow multiple "overlay bars" to be added so that side bars or corner panels with buttons can be added
=== Improve Layout Language ===
* ''Objective: make it easier to change the XUI layout data''
* Choose a standard model for the layout language (e.g. CSS? qt-like?)
* Allow elements to be grouped for layout purposes
* Auto layout elements when no layout information is provided
=== Enable Packaging and Resident customizations ===
JIRA: https://jira.secondlife.com/browse/VWR-1875
* ''Objective: enable external developers and residents to preserve changes across updates and distribute custom UI layouts''
* Allow residents to save changes to a user local directory (i.e. Documents and Settings\User\Application Data\SecondLife\skins)
* Allow residents to package changes and easily distribute them for easy installation by other users
** Define location to search for installed skin packages
** Include the ability to change skins and restore the original skin
=== Specific Requests ===
* Make iconic panels (i.e.. build tools) generally available
** Combination of fully iconic buttons and the ability for a button to open a specific tab in a floater

Skinning

2007-07-24T22:54:44Z

Gibson Willis: /* Remove hard coded art and colors from UI */

== Objectives ==
* Enable internal designers to more easily customize the look of Second Life
* Enable external developers and residents to save customizations and prepare skin "packages"
== Links ==
* [[User Interface Roadmap]]
== Task Descriptions ==
=== XUI Default Templates ===
JIRA: https://jira.secondlife.com/browse/VWR-1882
* ''Objective: Make the XUI files less verbose and more readable''
* Create 'templates.xml' file with default attributes for each widget type
** Other templates for common attribute sets can also be declared here
** Widgets can declare a tempate (default to the default one for that type)
* Remove all default values from the code (code cleanup)
* Create a tool to process all existing .xui files and write out only the non default values
** Clean up the XML output at the same time

=== UI Texture Cache ===
JIRA: https://jira.secondlife.com/browse/VWR-1883
* ''Objective: Make it easier to add and modify UI art''
* Separate pre-cached images with asset ids from UI images
* Rename UI Images to use file names not asset ids

=== Remove hard coded art and colors from UI ===
JIRA: https://jira.secondlife.com/browse/VWR-1884
* ''Objective: Remove any UI art from the code
* Remove programmatic art with attributes, e.g. volume sliders
* Remove any backgrounds from icons, etc (use alpha)
* Ensure that all images can be cropped and scaled
* Allow specification of fixed size borders (i.e. so that button graphics with narrow boarders scale correctly)
* Enable additional attributes to widgets for colors, etc

=== Facilitate UI customization ===
* ''Objective: Make it easier to see the effects of XUI edits''
* Enable reloading of all floaters including the menus and overlay bar
* Ensure all floaters can handle missing UI elements and will behave reasonably or refuse to open with an appropriate message
=== Facilitate customization of menus and overlay bar ===
* ''Objective: enable menus and overlay bar to be more easily customized''
* Create a global floater/panel map and have floaters/panels to specify their type (e.g. "floater_inventory" -> LLFloaterInventory) in XML
* Allow buttons to open floaters by name
** Include support for opening a specific tab
** Differentiate between toggling state of singletons, showing/focusing, and opening new instances
* Allow menus to be expanded/collapsed for simple/advanced usage
* Specify layout of overlay bar and menu bar in "viewer.xml"
** Allow multiple "overlay bars" to be added so that side bars or corner panels with buttons can be added
=== Improve Layout Language ===
* ''Objective: make it easier to change the XUI layout data''
* Choose a standard model for the layout language (e.g. CSS? qt-like?)
* Allow elements to be grouped for layout purposes
* Auto layout elements when no layout information is provided
=== Enable Packaging and Resident customizations ===
JIRA: https://jira.secondlife.com/browse/VWR-1875
* ''Objective: enable external developers and residents to preserve changes across updates and distribute custom UI layouts''
* Allow residents to save changes to a user local directory (i.e. Documents and Settings\User\Application Data\SecondLife\skins)
* Allow residents to package changes and easily distribute them for easy installation by other users
** Define location to search for installed skin packages
** Include the ability to change skins and restore the original skin
=== Specific Requests ===
* Make iconic panels (i.e.. build tools) generally available
** Combination of fully iconic buttons and the ability for a button to open a specific tab in a floater

Skinning

2007-07-24T22:52:27Z

Gibson Willis: /* UI Texture Cache */

== Objectives ==
* Enable internal designers to more easily customize the look of Second Life
* Enable external developers and residents to save customizations and prepare skin "packages"
== Links ==
* [[User Interface Roadmap]]
== Task Descriptions ==
=== XUI Default Templates ===
JIRA: https://jira.secondlife.com/browse/VWR-1882
* ''Objective: Make the XUI files less verbose and more readable''
* Create 'templates.xml' file with default attributes for each widget type
** Other templates for common attribute sets can also be declared here
** Widgets can declare a tempate (default to the default one for that type)
* Remove all default values from the code (code cleanup)
* Create a tool to process all existing .xui files and write out only the non default values
** Clean up the XML output at the same time

=== UI Texture Cache ===
JIRA: https://jira.secondlife.com/browse/VWR-1883
* ''Objective: Make it easier to add and modify UI art''
* Separate pre-cached images with asset ids from UI images
* Rename UI Images to use file names not asset ids

=== Remove hard coded art and colors from UI ===
* ''Objective: Remove any UI art from the code
* Remove programmatic art with attributes, e.g. volume sliders
* Remove any backgrounds from icons, etc (use alpha)
* Ensure that all images can be cropped and scaled
* Allow specification of fixed size borders (i.e. so that button graphics with narrow boarders scale correctly)
* Enable additional attributes to widgets for colors, etc
=== Facilitate UI customization ===
* ''Objective: Make it easier to see the effects of XUI edits''
* Enable reloading of all floaters including the menus and overlay bar
* Ensure all floaters can handle missing UI elements and will behave reasonably or refuse to open with an appropriate message
=== Facilitate customization of menus and overlay bar ===
* ''Objective: enable menus and overlay bar to be more easily customized''
* Create a global floater/panel map and have floaters/panels to specify their type (e.g. "floater_inventory" -> LLFloaterInventory) in XML
* Allow buttons to open floaters by name
** Include support for opening a specific tab
** Differentiate between toggling state of singletons, showing/focusing, and opening new instances
* Allow menus to be expanded/collapsed for simple/advanced usage
* Specify layout of overlay bar and menu bar in "viewer.xml"
** Allow multiple "overlay bars" to be added so that side bars or corner panels with buttons can be added
=== Improve Layout Language ===
* ''Objective: make it easier to change the XUI layout data''
* Choose a standard model for the layout language (e.g. CSS? qt-like?)
* Allow elements to be grouped for layout purposes
* Auto layout elements when no layout information is provided
=== Enable Packaging and Resident customizations ===
JIRA: https://jira.secondlife.com/browse/VWR-1875
* ''Objective: enable external developers and residents to preserve changes across updates and distribute custom UI layouts''
* Allow residents to save changes to a user local directory (i.e. Documents and Settings\User\Application Data\SecondLife\skins)
* Allow residents to package changes and easily distribute them for easy installation by other users
** Define location to search for installed skin packages
** Include the ability to change skins and restore the original skin
=== Specific Requests ===
* Make iconic panels (i.e.. build tools) generally available
** Combination of fully iconic buttons and the ability for a button to open a specific tab in a floater

Skinning

2007-07-24T22:48:43Z

Gibson Willis: /* XUI Default Templates */

== Objectives ==
* Enable internal designers to more easily customize the look of Second Life
* Enable external developers and residents to save customizations and prepare skin "packages"
== Links ==
* [[User Interface Roadmap]]
== Task Descriptions ==
=== XUI Default Templates ===
JIRA: https://jira.secondlife.com/browse/VWR-1882
* ''Objective: Make the XUI files less verbose and more readable''
* Create 'templates.xml' file with default attributes for each widget type
** Other templates for common attribute sets can also be declared here
** Widgets can declare a tempate (default to the default one for that type)
* Remove all default values from the code (code cleanup)
* Create a tool to process all existing .xui files and write out only the non default values
** Clean up the XML output at the same time

=== UI Texture Cache ===
* ''Objective: Make it easier to add and modify UI art''
* Separate pre-cached images with asset ids from UI images
* Rename UI Images to use file names not asset ids
=== Remove hard coded art and colors from UI ===
* ''Objective: Remove any UI art from the code
* Remove programmatic art with attributes, e.g. volume sliders
* Remove any backgrounds from icons, etc (use alpha)
* Ensure that all images can be cropped and scaled
* Allow specification of fixed size borders (i.e. so that button graphics with narrow boarders scale correctly)
* Enable additional attributes to widgets for colors, etc
=== Facilitate UI customization ===
* ''Objective: Make it easier to see the effects of XUI edits''
* Enable reloading of all floaters including the menus and overlay bar
* Ensure all floaters can handle missing UI elements and will behave reasonably or refuse to open with an appropriate message
=== Facilitate customization of menus and overlay bar ===
* ''Objective: enable menus and overlay bar to be more easily customized''
* Create a global floater/panel map and have floaters/panels to specify their type (e.g. "floater_inventory" -> LLFloaterInventory) in XML
* Allow buttons to open floaters by name
** Include support for opening a specific tab
** Differentiate between toggling state of singletons, showing/focusing, and opening new instances
* Allow menus to be expanded/collapsed for simple/advanced usage
* Specify layout of overlay bar and menu bar in "viewer.xml"
** Allow multiple "overlay bars" to be added so that side bars or corner panels with buttons can be added
=== Improve Layout Language ===
* ''Objective: make it easier to change the XUI layout data''
* Choose a standard model for the layout language (e.g. CSS? qt-like?)
* Allow elements to be grouped for layout purposes
* Auto layout elements when no layout information is provided
=== Enable Packaging and Resident customizations ===
JIRA: https://jira.secondlife.com/browse/VWR-1875
* ''Objective: enable external developers and residents to preserve changes across updates and distribute custom UI layouts''
* Allow residents to save changes to a user local directory (i.e. Documents and Settings\User\Application Data\SecondLife\skins)
* Allow residents to package changes and easily distribute them for easy installation by other users
** Define location to search for installed skin packages
** Include the ability to change skins and restore the original skin
=== Specific Requests ===
* Make iconic panels (i.e.. build tools) generally available
** Combination of fully iconic buttons and the ability for a button to open a specific tab in a floater

Skinning

2007-07-24T22:28:29Z

Gibson Willis:

== Objectives ==
* Enable internal designers to more easily customize the look of Second Life
* Enable external developers and residents to save customizations and prepare skin "packages"
== Links ==
* [[User Interface Roadmap]]
== Task Descriptions ==
=== XUI Default Templates ===
* ''Objective: Make the XUI files less verbose and more readable''
* Create 'templates.xml' file with default attributes for each widget type
** Other templates for common attribute sets can also be declared here
** Widgets can declare a tempate (default to the default one for that type)
* Remove all default values from the code (code cleanup)
* Create a tool to process all existing .xui files and write out only the non default values
** Clean up the XML output at the same time
=== UI Texture Cache ===
* ''Objective: Make it easier to add and modify UI art''
* Separate pre-cached images with asset ids from UI images
* Rename UI Images to use file names not asset ids
=== Remove hard coded art and colors from UI ===
* ''Objective: Remove any UI art from the code
* Remove programmatic art with attributes, e.g. volume sliders
* Remove any backgrounds from icons, etc (use alpha)
* Ensure that all images can be cropped and scaled
* Allow specification of fixed size borders (i.e. so that button graphics with narrow boarders scale correctly)
* Enable additional attributes to widgets for colors, etc
=== Facilitate UI customization ===
* ''Objective: Make it easier to see the effects of XUI edits''
* Enable reloading of all floaters including the menus and overlay bar
* Ensure all floaters can handle missing UI elements and will behave reasonably or refuse to open with an appropriate message
=== Facilitate customization of menus and overlay bar ===
* ''Objective: enable menus and overlay bar to be more easily customized''
* Create a global floater/panel map and have floaters/panels to specify their type (e.g. "floater_inventory" -> LLFloaterInventory) in XML
* Allow buttons to open floaters by name
** Include support for opening a specific tab
** Differentiate between toggling state of singletons, showing/focusing, and opening new instances
* Allow menus to be expanded/collapsed for simple/advanced usage
* Specify layout of overlay bar and menu bar in "viewer.xml"
** Allow multiple "overlay bars" to be added so that side bars or corner panels with buttons can be added
=== Improve Layout Language ===
* ''Objective: make it easier to change the XUI layout data''
* Choose a standard model for the layout language (e.g. CSS? qt-like?)
* Allow elements to be grouped for layout purposes
* Auto layout elements when no layout information is provided
=== Enable Packaging and Resident customizations ===
JIRA: https://jira.secondlife.com/browse/VWR-1875
* ''Objective: enable external developers and residents to preserve changes across updates and distribute custom UI layouts''
* Allow residents to save changes to a user local directory (i.e. Documents and Settings\User\Application Data\SecondLife\skins)
* Allow residents to package changes and easily distribute them for easy installation by other users
** Define location to search for installed skin packages
** Include the ability to change skins and restore the original skin
=== Specific Requests ===
* Make iconic panels (i.e.. build tools) generally available
** Combination of fully iconic buttons and the ability for a button to open a specific tab in a floater