SLDev-Traffic 1 - Revision history

Iron Perth: /* Plugin Autoupdater */

2007-03-03T20:57:05Z

Plugin Autoupdater

← Older revision		Revision as of 13:57, 3 March 2007
Line 106:		Line 106:
	== Plugin Autoupdater ==		== Plugin Autoupdater ==

	A developer suggested that the plugin system should support automatic updates from plugin authors' sites. The primary reason given was the headache of supporting thousands of users who might seek help from the plugin author every time a Viewer update broke old plugins.		Soft Noel expressed concern that autoupdating plugins would be a hard sell to LL as it makes the Viewer a potential vector for malware should plugin authors' update sites be hacked. On #opensl, Soft Noel suggested that, to head off anticipated LL liability concerns, a general purpose plugin updater could be written as a plugin and distributed with other plugins that used the updater.

	Soft Noel expressed concern that ~~this~~ would be a hard sell to LL as it makes the Viewer a potential vector for malware should plugin authors' update sites be hacked. On #opensl, Soft Noel suggested that, to head off anticipated LL liability concerns, a general purpose plugin updater could be written as a plugin and distributed with other plugins that used the updater.

	== Two Source Releases ==		== Two Source Releases ==

Rob Linden: Moving image to template

2007-03-03T20:54:43Z

Moving image to template

← Older revision		Revision as of 13:54, 3 March 2007
Line 1:		Line 1:
			{{SLDevTraffic}}

	sldev-traffic no 1		sldev-traffic no 1

	~~[[Image:sldev-traffic.gif\|SLDev Traffic]]~~

	sldev discussions through March 2, 2007		sldev discussions through March 2, 2007

Soft Noel: /* OpenJPEG patch (see VWR-123) still not merged */

2007-03-03T18:56:47Z

OpenJPEG patch (see VWR-123) still not merged

← Older revision		Revision as of 11:56, 3 March 2007
Line 211:		Line 211:
	SLDev members inquired through the list and IRC channel about whether GPL must be used for the plugin system. Developers have concerns about whether non-free plugins can be developed without complex circumvention measures. Rob Lanphier indicated that the issue is being pressed internally.		SLDev members inquired through the list and IRC channel about whether GPL must be used for the plugin system. Developers have concerns about whether non-free plugins can be developed without complex circumvention measures. Rob Lanphier indicated that the issue is being pressed internally.

	== OpenJPEG ~~patch (see VWR-123) still not merged~~ ==		== OpenJPEG Patch Not Merged ==

	Soft Noel ran into the known buffer overflow in LLImageJ2COJ::decodeImpl() using source version beta-1.13.4.3 on Intel Mac. She disabled jpeg decoding to continue to make progress.		Soft Noel ran into the known buffer overflow in LLImageJ2COJ::decodeImpl() using source version beta-1.13.4.3 on Intel Mac. She disabled jpeg decoding to continue to make progress.
	David Fries (SpacedOut Frye) (March 3rd) pointed out the fix in VWR-123 ~~on jira~~ which was first posted February 11th, ~~and~~ again asked why it hasn't made it into the source code release.		David Fries (SpacedOut Frye) (March 3rd) pointed out the fix in [https://jira.secondlife.com/browse/VWR-123 VWR-123], which was first posted February 11th, as well as a prior patch in [https://jira.secondlife.com/browse/VWR-94 VWR-94]. David Fries again asked why the fix hasn't made it into the source code release.

	~~David Fries posted a correction to his response. VWR-94 was the earlier patch to fix this buffer overflow which was posted a full month ago on February 3rd. It has been obsoleted by VWR-123 though~~.

SpacedOut Frye: self correction

2007-03-03T18:01:05Z

self correction

← Older revision		Revision as of 11:01, 3 March 2007
Line 214:		Line 214:

	Soft Noel ran into the known buffer overflow in LLImageJ2COJ::decodeImpl() using source version beta-1.13.4.3 on Intel Mac. She disabled jpeg decoding to continue to make progress.		Soft Noel ran into the known buffer overflow in LLImageJ2COJ::decodeImpl() using source version beta-1.13.4.3 on Intel Mac. She disabled jpeg decoding to continue to make progress.
	David Fries (SpacedOut Frye) (March 3rd) pointed out the fix in VWR-123 on jira, and again asked why it hasn't made it into the source code release.		David Fries (SpacedOut Frye) (March 3rd) pointed out the fix in VWR-123 on jira which was first posted February 11th, and again asked why it hasn't made it into the source code release.

			David Fries posted a correction to his response. VWR-94 was the earlier patch to fix this buffer overflow which was posted a full month ago on February 3rd. It has been obsoleted by VWR-123 though.

SpacedOut Frye: added OpenJPEG patch (see VWR-123) still not merged

2007-03-03T17:29:16Z

added OpenJPEG patch (see VWR-123) still not merged

← Older revision		Revision as of 10:29, 3 March 2007
Line 210:		Line 210:

	SLDev members inquired through the list and IRC channel about whether GPL must be used for the plugin system. Developers have concerns about whether non-free plugins can be developed without complex circumvention measures. Rob Lanphier indicated that the issue is being pressed internally.		SLDev members inquired through the list and IRC channel about whether GPL must be used for the plugin system. Developers have concerns about whether non-free plugins can be developed without complex circumvention measures. Rob Lanphier indicated that the issue is being pressed internally.

			== OpenJPEG patch (see VWR-123) still not merged ==

			Soft Noel ran into the known buffer overflow in LLImageJ2COJ::decodeImpl() using source version beta-1.13.4.3 on Intel Mac. She disabled jpeg decoding to continue to make progress.
			David Fries (SpacedOut Frye) (March 3rd) pointed out the fix in VWR-123 on jira, and again asked why it hasn't made it into the source code release.

SpacedOut Frye: corrected and expanded entry

2007-03-03T17:18:27Z

corrected and expanded entry

← Older revision		Revision as of 10:18, 3 March 2007
Line 188:		Line 188:
	== Linux Viewers and 3D Acceleration ==		== Linux Viewers and 3D Acceleration ==

	Truxpin was having difficulty making Second Life run on his machine using open source nVidia drivers. ~~David Fries offered a patch for starting SL in 16 bit mode if 24 bit mode failed, however it caused Truxpin's machine to revert to software rendering.~~ David Fries states that Linden Lab currently requires 24 bit ~~mode~~, while Mesa only supports 16 bit depth. ~~This apparently means~~ that ~~nVidia users will require~~ the ~~closed source driver for full 3D acceleration~~.		Truxpin was having difficulty making Second Life run on his machine using open source nVidia drivers. David Fries states that Linden Lab currently requires a 24 bit depth buffer, while Mesa only supports 16 bit depth. David Fries (SpacedOut Frye) offered a patch that would request an OpenGL context with a 16 bit depth buffer if the 24 bit depth buffer request failed.

			Truxpin posted an e-mail including glxinfo which showed,
			direct rendering: No
			server glx vendor string: SGI
			Indicating he only had software OpenGL rendering available. The patch allowed the Second Life viewer to run with a 0.7 frame rate which also indicated software rendering.

			Truxpin later posted (off list) that he was able to get the nVidia driver installed and running at about the same speed under Linux as Windows on that computer.

			nVidia users currently require the closed source driver for 3D OpenGL acceleration.

	== Linden Lab and Open Source ==		== Linden Lab and Open Source ==

Soft Noel: If you want to remove your name, please make the remaining text make sense

2007-03-03T14:54:10Z

If you want to remove your name, please make the remaining text make sense

← Older revision		Revision as of 07:54, 3 March 2007
Line 105:		Line 105:

	== Plugin Autoupdater ==		== Plugin Autoupdater ==

			A developer suggested that the plugin system should support automatic updates from plugin authors' sites. The primary reason given was the headache of supporting thousands of users who might seek help from the plugin author every time a Viewer update broke old plugins.

	Soft Noel expressed concern that this would be a hard sell to LL as it makes the Viewer a potential vector for malware should plugin authors' update sites be hacked. On #opensl, Soft Noel suggested that, to head off anticipated LL liability concerns, a general purpose plugin updater could be written as a plugin and distributed with other plugins that used the updater.		Soft Noel expressed concern that this would be a hard sell to LL as it makes the Viewer a potential vector for malware should plugin authors' update sites be hacked. On #opensl, Soft Noel suggested that, to head off anticipated LL liability concerns, a general purpose plugin updater could be written as a plugin and distributed with other plugins that used the updater.

Iron Perth: /* Plugin Autoupdater */

2007-03-03T10:46:02Z

Plugin Autoupdater

← Older revision		Revision as of 03:46, 3 March 2007
Line 106:		Line 106:
	== Plugin Autoupdater ==		== Plugin Autoupdater ==

	Tim Shephard voiced concern that the plugin system should support automatic updates from plugin authors' sites. The primary reason given was the headache of supporting thousands of users who might seek help from the plugin author every time a Viewer update broke old plugins. Soft Noel expressed concern that this would be a hard sell to LL as it makes the Viewer a potential vector for malware should plugin authors' update sites be hacked. On #opensl, Soft Noel suggested that, to head off anticipated LL liability concerns, a general purpose plugin updater could be written as a plugin and distributed with other plugins that used the updater.		Soft Noel expressed concern that this would be a hard sell to LL as it makes the Viewer a potential vector for malware should plugin authors' update sites be hacked. On #opensl, Soft Noel suggested that, to head off anticipated LL liability concerns, a general purpose plugin updater could be written as a plugin and distributed with other plugins that used the updater.



	== Two Source Releases ==		== Two Source Releases ==

Iron Perth at 08:08, 3 March 2007

2007-03-03T08:08:04Z

← Older revision		Revision as of 01:08, 3 March 2007
Line 57:		Line 57:
	Tofu Linden noted that he had committed a change to make disabling LLMozLib easier, and that it should reach the open source release soon.		Tofu Linden noted that he had committed a change to make disabling LLMozLib easier, and that it should reach the open source release soon.


			== C++ bindings Prototype versus C ==

			Tim Shephard posted a C++ prototype which proved that it was possible to develop a plugin API which interfaced via C++ and inheritance. However, the issues he ran into were that you would need to build with the same compiler (both client and plugin) in order to develop compatible binaries. This was a significant non starter.

			He also discussed the NPAPI API as a simple model for plugins.

Soft Noel: /* C++ motivated Plugin Bindings */

2007-03-03T08:04:02Z

C++ motivated Plugin Bindings

← Older revision		Revision as of 01:04, 3 March 2007
Line 64:		Line 64:

	The significant concern as pointed out by Tim Shephard in an earlier posting as mentioned above, is that C++ has significant Application Binary Issues on the Windows platform. (Microsoft has not guaranteed that they will support the C++ ABI from one release to the next (in fact, it changed in VS2003 -> VS2005)). This will make it difficult to support people who build their plugins with a different compiler than what Linden Lab is using.		The significant concern as pointed out by Tim Shephard in an earlier posting as mentioned above, is that C++ has significant Application Binary Issues on the Windows platform. (Microsoft has not guaranteed that they will support the C++ ABI from one release to the next (in fact, it changed in VS2003 -> VS2005)). This will make it difficult to support people who build their plugins with a different compiler than what Linden Lab is using.

			Argent Stonecutter suggested that the bindings should be as language-neutral as possible, noting that targeting C was targeting the lowest common denominator of all languages. Soft Noel is reworking the posted system to offer a C interface instead of C++. Argent Stonecutter voiced concern about the anonymous pointers C would introduce in the plugin API and referenced an older thread. In that thread, he laid out one scheme for encoding plugin parameter formats and described the behavior plugins would follow in validating such a plugin interface. Ryan Williams suggested that the already existent LLSD would work for a plugin interface with this design and noted likely similarity between a plugin API and the messaging system.

	== Keep It Simple ==		== Keep It Simple ==