F20 System Wide Change: Web Assets

[T.C. Hollingsworth]

On Mon, Aug 12, 2013 at 1:05 PM, Robert Marcano
<robert at marcanoonline.com> wrote:
> On 08/12/2013 03:23 PM, Robert Marcano wrote:
>>
>>
>> This is a better explanation of why the use /usr/share/javascript: We
>> want to be compatible with others distribution that have the legacy idea
>> that JavaScript is a browser only thing, so in this directory we will
>> only store JavaScript that run on the browser
>
>
> Sorry, I missed this:
>
> "If a JavaScript library can be executed locally or consists purely of
> JavaScript code, it must be installed into a subdirectory of %{_jsdir}."
>
>
> and the Feature says:
>
> "Additionally the following symlinks will be provided:
>
>     /usr/share/web-assets/javascript points to /usr/share/javascript"
>
> So non browser JavaScript code will be shared via HTTP?, all those pages are
> out of sync that it is difficult to understand what will go to each place

So one possible option that would address your concerns would be to
require every js-foo package to also provide a webjs-foo subpackage or
so that just contains a symlink in /usr/share/web-assets/js to the
appropriate location in /usr/share/javascript.

That would provide a way for dependent packages to express "hey, I
just need you on the server-side" and another way to say "hey, I need
you served over HTTP".

But then, what do we want to do about fonts?  Adding *-webfonts
subpackages to every font package would be a lot of work, and makes
that awesome WordPress usecase I mentioned much, much harder.  What
about CSS?  Do we really need a css-bootstrap for when someone wants
to create a locally run HTML5 application with something like
node-webkit and another webcss-bootstrap for when they really want it
served over HTTP?

It's really a lot of work optimizing for what is an edge case.  I'm
not convinced it's necessary, but I'll mention this to FPC during my
meeting with them on Thursday for their input anyway.

-T.C.