On 08/06/2013 10:46 AM, Miloslav Trmač wrote:
On Tue, Aug 6, 2013 at 5:27 AM, Robert Marcano <rob...@marcanoonline.com> wrote:
You make the decision by installing a js-foo package, just like you
make the decision to provide a web application by installing a package
for it.
"You make a decision by installing a package" is a really problematic
model, e.g. because packages can be dragged in by dependencies.
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
There is actually a precedent for that - our default httpd
configuration aliases /icons, see e.g.
https://fedoraproject.org/icons/apache_pb2.png . OK, these are "only"
public domain; then let's see httpd-manual, which publishes
Apache-licensed documentation in /manual.
And I don't see a problems with those examples, because they share only
their contents, by installing them you don't share content from other
packages.
Lets make an example of the mess this will create if I want to share a
web application to the world and user another one on my intranet. I will
call those Internet and Intranet application
Internet application requires JavaScript library intranet-library, and
the same with intranet-library.
Both applications are installed, I as a sysadmin don't want to expose
intranet used assets to the general public, so I need to make changes on
it's respective apache configuration file in order to explicitly block
/usr/share/web-assets/javascript/intranet-library.
A new update to intranet application adds a new requirement.
new-intranet-library. So I as a sysadmin must be checking every package
installed in order to see if it is exposing more things to the public.
You can have many reasons for not wanting that, license of those files,
avoid people linking to them and use your bandwidth.
I am not against creating some order and removing the privilege that
JavaScript code and assets currently have of being allowed to be bundled
on every package. But sharing /usr/share/fonts and /usr/share/javascript
by default is bad.
I think web applications should link themselves to each asset they need
on its directory/namespace. You will probably loose the advantage of
having only one URL for the same file if you install multiple web
applications, but you gain more control having each application using
one directory/namespace and only one
SELinux must be taken into consideration too, be it that those
directories get finally shared entirely or not. Will be created a new
SELinux context for font (already exist), JavasScript code and other
files?, in order to allow Apache to read files outside /var/www. With
the current way of packaging of bundling everything this wasn't a
problem because files were part of the application, not anymore with
these proposal
(That's not necessarily a good argument that it's OK to do this way, I
just wanted to point out that this is not that new.)
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
