On Mon, Aug 5, 2013 at 8:27 PM, Robert Marcano <robert@xxxxxxxxxxxxxxxxx> wrote:
> Do you know there are GNOME JavaScript applications? And that JavaScript is
> being encouraged as a language for desktop applications? So all those
> libraries that can be used on desktop and web clients will be shared by
> default if I install a desktop application that need that library and a web
> application that never uses that library? This is madness, why not share
> /usr/bin via NFS too by default
Yes, and they certainly don't belong in the *Web Assets* directory.
This is about JavaScript for the web, not every place under the sun in
which it is embedded.
Software which embeds languages usually use their own directory for
the libraries involved. Blender doesn't drop a bunch of crap in
%{python_sitelib} that is only useful to it, and GNOME won't be
dropping a bunch of stuff in %{_jsdir} that is completely useless on
the web since it involves C bindings.
I might add that the policies being implemented here really don't make
sense for non-web JS anyway. Minification is pointless for GNOME
shell extensions, since the entire point of minification is to reduce
HTTP transfer times. Additionally, we don't want the static inclusion
exception to be permitted for server-side or embedded JS. It's not
the '90s anymore; they should be getting libraries right.
I just made a series of changes to the draft JavaScript guidelines
that enforce what I said above.
> This is a licensing problem. I should not need to disable it, because I
> think Fedora should not share code/assets only because I installed it, the
> we application need to share it if it is really needed. I think I a being
> repetitive here NAD nobody understand my point of view :-( probably I
> should ask on fedora-legal, I don't like where this is going, making me a
> distributor by default of every JavaScript package installed even if no web
> application needs them
Who is going to install "js-jquery" and never want to use it on a web
server? Yeah, these will get dragged in as dependencies, but if a web
application `Requires: js-jquery`, that's it saying it needs it!
Yeah, a couple of these libraries can be used by server-side JS
runtimes. But if you install coffee-script, I as a packager can't
psychically divine whether you intend to compile all your coffee
script to JS prior to serving it or dynamically compile it on the fly,
so it makes sense *by default* to support both use cases. And really,
if you're precompiling I sincerely hope you're not doing it on your
production server, in which case you just won't have coffee-script
installed on your server at all.
I think the defaults here are useful for 99% of people's use cases,
and open up a bunch of new ones.
Wouldn't it be cool if you could change your blog's font by just
installing it and selecting it from a drop-down box in WordPress?
Without having to figure out how to make Apache include it? Oh wait,
most users aren't going to mess around with Apache configs, they're
just going to `cp` it to /var/www/html, and when it gets updated
because a glyph gets rendered wrong the copy on their web server will
be outdated forever. :-(
The days where every web application and framework knows exactly what
libraries it needs are over. How can the rails maintainer know if the
dev wants to use jQuery, or Bootstrap, or Angular? We can either make
it dead simple for them to use system versions of these libraries
(just `yum install bootstrap`, add a <link> tag to your template, and
BAM! it's there!), or again they'll just keep dropping copies in their
directories like they've been doing forever.
We have a really good set of tools for distributing and keeping stuff
up-to-date, and it would be really, REALLY nice if they could be
applied to stuff exported over web servers too, but nobody's going to
use our work if we make it too damn difficult for them to use. :-(
This is just one piece of the puzzle, but it's an important first step. :-)
-T.C.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
