Radomir Dopieralski <openst...@sheep.art.pl> writes: > On 21/01/15 09:21, david.co...@oracle.com wrote: >>> As for our work and updates, using system-wide packages is an >>> excellent solution in this regard, as we get maintenance and updates >>> for free. For instance, if there is a security issue in one of the >>> JavaScript libraries, we don't need to patch Horizon -- the patch >>> that is prepared for that specific library and applied system-wide >>> is sufficient. >> >> But for distributions that package Horizon itself, don't they >> effectively need to patch Horizon? Namely, don't they need to install >> on their build systems fixed JavaScript distribution packages to >> address the security issue and then they need to rebuild Horizon >> itself even if there are no Horizon source code changes. >> >> From a Horizon end-user perspective who relies on the distribution's >> packages to get Horizon, they'll get the security fix but it seems >> distributors will still need to rebuild and deliver Horizon for every >> upstream JavaScript fix whether the files come from XStatic, Bower, >> or some other method. > > No, why would they? They don't copy the static files into the > Horizon's package. That's the whole point, Horizon only has paths to > them. The files themselves are provided by the system-wide packages.
This seems to imply that users will download at least one .js file per dependency. That's probably acceptable for an application like Horizon which users will be using again and again, but for most web applications, you don't want your users to download 10-20 small .js files, instead you want them to download one minified and compressed file with all the JavaScript code needed. I'm just mentioning this since it's one way that web apps differ from how normal Linux apps are typically deployed. Basically, web apps prefer static compilation and discourages "dynamic linking". -- Martin Geisler http://google.com/+MartinGeisler
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
