launchpad-dev team mailing list archive

[Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx>]

This should be my last one, I hope. :-)  And it's just to clarify
this, for people who care about the packaging story for JavaScript.

On Sun, Feb 13, 2011 at 9:02 PM, Gary Poster <gary.poster@xxxxxxxxxxxxx> wrote:
>
> Here's a summary of my understanding.  Please correct.
>
> - We all like working with packaged software.
> - YUI has a story for this.  It is a story that the JS experts at Canonical have rejected: using Yahoo's CDN.

No one really rejected using Yahoo's CDN.  I think all of us would
prefer this.  It doesn't support SSL.

http://developer.yahoo.com/yui/articles/faq/#cdnssl

So it wasn't so much rejected and much as just not possible.  If you
don't use the CDN, Yahoo recommends building a single js file and
using that, which has been the approach until now.  But that doesn't
scale with the growth of YUI, and now we want to do a combo loader.
There are some other issues with using a combo loader and our setup
that contributed to the single file approach initially, too.

> - lazr-js was supposed to be Canonical's story for this.  It has at least two problems.
>   * First, it uses Python build tools for something that is JS only.  We're already off on our own since we are not using the CDN, and this makes it more isolated.  [I vaguely think there are other problems with this too?]

It adds a layer between development.  You can't do anything in lazr-js
(or Launchpad js) without a build step, which is heavy handed for js
development.  See this entire discussion.  If lazr-js was just a bzr
branch, Brad could have added the gallery file and kept rolling with
development.

Also, it takes for freakin' ever to build lazr-js trunk on its own for
the first time.  For what?  To run 200 tests? ;)  This block adoption
of lazr-js across the company or outside the company.

>   * Second, it is a shared resource, shared across Canonical.  This encourages slower, more thoughtful changes that look towards building company-wide consensus.  It is less appropriate for quick, application-specific work.
>  - Because of this, the Canonical JS experts are excited and pleased for Paul to do the work he describes.
>

Yup, exactly.  This will all get better with Paul's work, but we
should still be thoughtful about what we pull into lazr-js.  It should
be a shared library, not a place to dump every single js fcould have
added the gallery file and kept rolling with development.ile we might
one day use.

Cheers,
deryck

-- 
Deryck Hodge
https://launchpad.net/~deryck
http://www.devurandom.org/