> On 2015-02-24 17:10 , Henri Beauchamp wrote: > > On Tue, 24 Feb 2015 15:37:21 -0600, Nicky Perian wrote: > > > >> Plugins are no longer built in the viewer but, are delivered > >> as content in an archive. > > Which means TPV developers will not be able any more to fix bugs in the > > plugins and will have to endure the very same bugs as the ones plagging > > LL's viewer... > > Not at all - the repository that builds the plugins is public. > > https://bitbucket.org/lindenlab/3p-update-slplugins
>>> And I confirm my assertion.. See by yourself: that link points to a >>> repository which holds only *binaries* (no source at all !): how >>> would TPV developers fix bugs and provide/use fixed binaries >>> without the sources ??? @Oz Will we have to keep the old tools active to rebuild the plugin binaries and then piece together archives to use in the new tools? If so, that is unsatisfactory. 3p-update-slplugins needs to standalone and be able to produce an archive without having to rely on the outdated tools. On Fri, Feb 27, 2015 at 10:20 AM, Henri Beauchamp <sl...@free.fr> wrote: > On Fri, 27 Feb 2015 09:23:19 -0500, Oz Linden (Scott Lawrence) wrote: > > > On 2015-02-24 17:10 , Henri Beauchamp wrote: > > > On Tue, 24 Feb 2015 15:37:21 -0600, Nicky Perian wrote: > > > > > >> Plugins are no longer built in the viewer but, are delivered > > >> as content in an archive. > > > Which means TPV developers will not be able any more to fix bugs in the > > > plugins and will have to endure the very same bugs as the ones plagging > > > LL's viewer... > > > > Not at all - the repository that builds the plugins is public. > > > > https://bitbucket.org/lindenlab/3p-update-slplugins > > And I confirm my assertion.. See by yourself: that link points to a > repository which holds only *binaries* (no source at all !): how > would TPV developers fix bugs and provide/use fixed binaries without > the sources ??? > > > that will move to 3p-slplugins when we release the tools update viewer > > (which should be going to release candidate very shortly). > > > > > Not at all... The proper and only "clean" solution would be to get > > > fully rid of the Quicktime dependency for the builds... Quicktime > > > is totally outdated anyway. > > > > I see no reason to remove support for any Quicktime content people may > > have in SL if we can avoid it. > > You may perfectly read Quicktime encoded files using other libraries > (including open source ones) than that old Quicktime SDK... > All what I said is that it is time to drop that old Quicktime for > Windows SDK and use another (preferably an open source one) instead. > > > We are very actively working on updating the web media subsystem; > > whether or not it will maintain exactly the current plugin strategy, and > > whether or not it will be possible to keep Quicktime working are still > > to be determined. Stay tuned. > > Glad to know there's work being done... I'd wish it would be done in the > open however... Any chance to get a public repository open for the > current work in progress ? > > Henri. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
