F20 System Wide Change: Web Assets

Robert Marcano robert at marcanoonline.com
Thu Aug 8 19:22:35 UTC 2013


On 08/06/2013 05:10 PM, T.C. Hollingsworth wrote:
> On Mon, Aug 5, 2013 at 8:27 PM, Robert Marcano <robert at marcanoonline.com> 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.

The directory is not called /usr/share/web-javascript, it is called 
/usr/share/javascript, and the packaging guidelines draft explicitly 
says that the intention is to avoid duplication of libraries, so it is 
calling to move all JavaScript reusable code/frameworks/libraries to it, 
not only browser based JavaScript, and I quote:

"There are also some JavaScript libraries which are intended to be used 
on the local system, not served via a web server to a browser. These 
libraries clearly have all the standard reasons to avoid duplication."

and later it contradict what you say, indicating that they must use

"BuildRequires:  web-assets-devel" and
"Requires:  web-assets-filesystem"

So, it means all JavaScript, even the used on the local system must 
depend of web-assets

>
> 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.
>



More information about the devel mailing list