On Wed, Jan 20, 2010 at 10:30 AM, John Hjelmstad <fa...@google.com> wrote:
> On Wed, Jan 20, 2010 at 1:11 AM, Paul Lindner <plind...@linkedin.com>
> wrote:
>
> > I've been looking into the javascript code lately so we can get it ready
> to
> > be processed by the closure compiler. I have some changes I'd like to
> put
> > in place that I believe would be useful:
> >
> > * Create a globals and/or base feature that holds the global variables,
> > gadgets (for gadgets) and shindig (for internal shindig namespace). Most
> > modules would then add a dependency to this feature. This would then
> allow
> > for us to remove many of the duplicated lines like this:
> >
> > var gadgets = gadgets || {};
> >
>
> Sounds fine. All core.* should depend on core.globals then.
>
>
I'll apply this patch later today
>
> >
> > etc.
> >
> > * Try to make features 1-1 with the javascript namespace they define.
> > core.prefs -> gadgets.prefs
> > core.util -> gadgets.util
> > core.auth -> shindig.Auth
> > core.json -> gadgets.json
> > pubsub -> gadgets.pubsub
> > core.io -> gadgets.io
> > flash -> gadgets.flash
>
> That was the intent w/ my previous changes, and with the exception of
> core.legacy it seems this is largely done. Which one(s) am I missing?
To make things absolutely clear I would rename the directory structure to
correspond to the javascript namespace. The above list shows how the
directories would be renamed.
>
> >
> > * move xmlutil from opensocial.xmlutil to shindig.xmlutil (and any other
> > pollution of the opensocial namespace)
> >
>
> +1.
>
>
> >
> > * Somehow maintain a closure compiler externs file (could go
> hand-in-hand
> > with the taming.js maintenance?)
> >
>
> taming.js's semantics are somewhat different in that they should only be
> included when processing content w/ Caja. Jasvir and I have a TODO on our
> plates to add that filtering.
>
> Is your proposal to maintain a "master" externs file? Typically externs are
> managed on a per-bundle basis (eg. per-feature).
We could maintain an externs.js file for each feature. My thoughts were to
somehow convert that to the taming.js file since they both essentially
document the public API.
> >
> > * To assist with exporting symbols use nomenclature like this:
> >
> > gadgets.log['INFO'] = 1;
> >
> > instead of gadgets.log.INFO = 1;
> >
> > This signifies a namespace that should not be renamed
> >
> > Thoughts on any of this? I have some patches I'm testing, more to
> come...
> >
>
> Sounds great, thanks for taking this up! Your thoughts on plugging Closure
> Compiler dynamically into the rendering pipeline? I've long been interested
> in doing so and plan to get to it if ever I can clear my current plate ;)
Sadly I don't think it would be possible to bundle closure-compiler directly
with shindig since it contains closed-source jars, requires Java 6 and also
seems to incorporate rhino (which I believe is LGPL/GPL/MPL, not Apache
licensed)
As an optional build-time component I think we're okay.
