[Bug 457343] Review Request: jquery - Fast, concise library that simplifies how you use javascript

bugzilla at redhat.com bugzilla at redhat.com
Tue Nov 30 17:18:39 UTC 2010


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=457343

--- Comment #5 from Toshio Ernie Kuratomi <a.badger at gmail.com> 2010-11-30 12:18:37 EST ---
Hey Steven, going to what MochiKit does is probably a step backwards from what
is posted in my last package.  I was doing this package while working on the
JavaScript Guidelines and during that process we basically started with what
MochiKit did and made improvements from there.

This basically stalled because I wanted to get the Packaging Guidelines for
JavaScript working but got lost in technical issues with it for a while. 
Here's the draft documentation:
https://fedoraproject.org/wiki/JavaScript_libraries_packaging_guideline_draft

If you'd like to work on the draft a lot of people would be very pleased!  The
things that came up when the FPC discussed it were:

1) We should make a distinction between JavaScript intended to be served to
browsers and JavaScript which can be run on the local machine.  For instance,
KDE now has javascript bindings.  The JavaScript on local machines may have
tougher security considerations than JavaScript run on browsers.  It should
probably go in different directories than the browser-libraries, etc.

2) Over time I've come to believe that a static linking model is more
appropriate than a dynamic linking model for browser based JavaScript.  As an
example, an application needing jquery would use the code in this package when
it builds but it would be free to copy the jquery from this package into
itself.  When this jquery package updates, the web application would need to be
ported to the new version of jquery at that time.  Provides and Requires
similar to that used for static linking would be used to track what libraries
at what versions are being statically linked.

3) We need to anticipate handling of multiple versions of a library.  For many
years, we're going to find that different applications work with different
upstream versions of a javascript library.  Only after we've been packaging for
a time will it become normal for upstreams to port to newer versions of the
JavaScript libraries as they come out just like they port to newer versions of
their server-language's libraries.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the package-review mailing list