Difference between revisions of "SLDev-Traffic 12"
Seg Baphomet (talk | contribs) |
Alissa Sabre (talk | contribs) |
||
Line 19: | Line 19: | ||
Alan Grimes notes that the unicode.ttf link is invalid with his *nix distribution. Tofu Linden replied, saying that the link is an interim workaround until fontconfig support is implemented. The link can be treated as a reminder to add an appropriate link if the link is invalid for a given system. | Alan Grimes notes that the unicode.ttf link is invalid with his *nix distribution. Tofu Linden replied, saying that the link is an interim workaround until fontconfig support is implemented. The link can be treated as a reminder to add an appropriate link if the link is invalid for a given system. | ||
Alissa Sabre followed up with a fontconfig patch. There was no indication that the patch had been added to the JIRA. The patch can be found in Alissa's | Alissa Sabre followed up with a fontconfig patch. There was no indication that the patch had been added to the JIRA. The patch can be found in Alissa's {{sldev|2007-May|001869|original message}}. Alissa started [[User:Alissa Sabre/Notes on fontconfig|a page]] on the issue. | ||
== Privacy Pockets == | == Privacy Pockets == |
Latest revision as of 09:11, 21 June 2007
sldev-traffic no 12
sldev discussions through May 18, 2007
OpenAL Support Patch
Callum Lerwick posted a patch enabling OpenAL support - OpenAL is an open source audio library that is to audio what OpenGL is to 3D graphics. Callum has tested the patch under Linux only, and lists a few problems. There was no follow-up conversation on the list. The patch can be found attached to the original announcement.
This could be a first step toward eliminating the need for fmod. In the past, there has also been discussion of replacing fmod with gstreamer, but no patches have been submitted.
- Actually, the two would be complementary. OpenAL has no support for MP3 streaming like fmod has, so I plan to use gstreamer to supply the necessary MP3 codec and network code on Linux. This would prevent slviewer from having to depend directly on an mp3 codec which would open up patent licensing issues, and provides an easy way for a user to aquire a legitimate MP3 codec. (Fluendo) And it saves me from having to write any network code... Seg Baphomet 21:55, 27 May 2007 (PDT)
Boo to BOOL
Alan Grimes attempted a patch converting all BOOLs to standard C++ bools, and posted a rough benchmark showing less runtime consumed when running for "about ten minutes," as well as a smaller memory footprint. Paul Hampson looked over the large patch and noted some changes that would cause problems or that didn't change code as intended. After some further discussion, Andrew Meadows (Linden) suggested that an all-at-once BOOL to bool patch would not work. In summary, there were too many opportunities for subtle bugs to be introduced, and the patch would go stale fast in touching so many systems at once. He suggested that the best SLDev members could do would be to make all new code use bools and to make BOOL to bool conversions opportunistically when submitting patches in local code -- eventually a sweeping replacement would be easier to effect.
unicode.ttf Link
Alan Grimes notes that the unicode.ttf link is invalid with his *nix distribution. Tofu Linden replied, saying that the link is an interim workaround until fontconfig support is implemented. The link can be treated as a reminder to add an appropriate link if the link is invalid for a given system.
Alissa Sabre followed up with a fontconfig patch. There was no indication that the patch had been added to the JIRA. The patch can be found in Alissa's original message. Alissa started a page on the issue.
Privacy Pockets
A very wide-reaching discussion of the need for and design of privacy pockets continues. Some SLDev members questioned the need and effectiveness. Justifications for the need for privacy were given that didn't just pertain to sexual activities, but also business meetings, development of projects under non-disclosure, and the cost-effectiveness of private islands as the current only privacy solution. The effectiveness of the pockets varied with the proposed implementation - there were many proposals, all centering around the theme of making the contents of a pocket invisible to other classes of users, be they predefined sets, owner-customizable sets, or users not entering the same WoW-like "instances" with multiple parallel instantiations of the same space.
List members noted that there has been resistance to changing the size of the usable vertical area of a region, and that proposals for putting the private areas below 0 meters or above the current 768ish height were likely to present non-trivial technical challenges. In reply to a discussion about the scaling challenges of pockets, which might affect different users' view of the map, Kelly Washington (Linden) posted, noting that anything that had an effect localized to a region wasn't a scaling issue - but things that affected non-local users, such as the contents of the global map, did present scaling issues.
There haven't been any hard conclusions, and near-term patches are unlikely as this would largely be a server-side implementation issue.