Web Assets
Summary
Traditionally, Fedora has been pushing bits from its various servers to people's browsers in an ad-hoc fashion, and issues surrounding JavaScript have been swept under the rug. This change proposal provides a simple framework for handling involved packages and a way forward to treat JavaScript more closely to other code in the distribution.
Owner
- Name: T.C. Hollingsworth
- Email: tchollingsworth@gmail.com
Current status
- Targeted release: Fedora 20
- Last updated: 2013-07-10
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
A standard directory (/usr/share/assets) for static bits that are intended to be delivered to web browsers, such as CSS Frameworks, UI libraries, etc. will be introduced. HTTP daemons in the distribution should make this directory available publicly as /assets.
Additionally, a standard directory (/usr/share/javascript) for JavaScript code, which may be used in browsers or server-side by applications such as nodejs or rubygem-execjs will also be introduced.
Finally, new packaging guidelines will provide instructions for making proper use of these new directories.
Benefit to Fedora
Packagers will benefit from clear guidelines for shipping JavaScript code and other modular content that can be used by multiple web applications.
By eliminating bundling of JavaScript code within web applications and replacing it with proper packaging, the security footprint of the distribution will be improved.
Scope
The web-assets RPM
A web-assets package will be introduced.
The web-assets-filesystem subpackage will be provided, which contains the following directories:
/usr/share/assets/usr/share/javascript
Additionally the following symlinks will be provided:
/usr/share/javascript -> /usr/share/assets/javascript/usr/share/fonts -> /usr/share/assets/fonts(so any Fedora font package can be used as a web font)
A web-assets-devel subpackage will be provided that provides macros like %{_assetdir} and other conveniences described in the proposed guidelines.
HTTP daemons
All HTTP daemons in the distribution should make the /usr/share/assets directory available publicly as /assets.
JavaScript packagers
Some longstanding reviews (like jquery) can now be completed with clear guidelines, paving the way for web applications to start being migrating to using proper dependencies instead of bundling.
All web applications currently in the distribution should be examined for bundled JavaScript, which should be packaged separately.
Web application packagers
Web applications can migrate to new JavaScript/Web Asset packages as they become available.
There are a lot of potentially affected packages. There's no hope of fixing them all in one release cycle, and even the dependency chain for jQuery, a big ticket package, could take several months to get reviewed and imported. Therefore, this Change proposal just seeks FESCo/FPC approval for a start to unravelling this madness. This will be a long transition, and will probably make the systemd transition look like a day in the park.
FPC
The Fedora Packaging Committee will need to consider and approve drafts pertaining to Web Assets and JavaScript.
FPC/FESCo
FPC/FESCo may or may not want to consider a firm date for sunsetting the bundled JavaScript exception and requiring all new packages to meet the new guidelines.
Upgrade/compatibility impact
None at this time.
Web Applications migrating their dependencies to the new framework will need to take care to provide a sane upgrade path, but that should be relatively simple.
How To Test
- Make sure the directories exist.
- Install [[#Dependencies|a HTTP daemon], and verify that you can navigate to
http://localhost/assets/andhttp://localhost/assets/javascript/.
User Experience
Web Developers who want to use these libraries and frameworks in their applications will have a single place to look going forward.
Dependencies
Potentially affected HTTP daemons:
- httpd
- lighttpd
- nginx
FAQ
Using /usr/share/javascript allows for consistency with other distributions (like Debian) and reflects the fact that JavaScript code can be run on Fedora itself as well as being pushed to the browser.
Why not just ship Apache configuration files for this kind of stuff like we've been doing/has been suggested before?
That leaves other http daemons and servers that don't involve traditional HTTP daemons (like many Node.js applications) hung out to dry. By just using a single, standard directory, and making that accessible from all HTTP daemons, support for many HTTP daemons is provided, and the need for packagers to keep up with changing Apache configuration formats just to ship a few simple JS files is eliminated.
Contingency Plan
None needed, either the directories get added or they don't.
Documentation
The new Packaging Guidelines referenced above.
Release Notes
Fedora 20 introduces standard directories for web assets (such as web user interface libraries) in /usr/share/assets, and JavaScript code in /usr/share/javascript. In future releases, web applications will be migrated to using shared components, eliminating the need for security updates to the same code in multiple packages.