You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Paul Lindner <pl...@linkedin.com> on 2010/01/20 10:11:24 UTC
proposed javascript refinements
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 || {};
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
core.prefs -> gadgets.Prefs?
* move xmlutil from opensocial.xmlutil to shindig.xmlutil (and any other
pollution of the opensocial namespace)
* Somehow maintain a closure compiler externs file (could go hand-in-hand
with the taming.js maintenance?)
* 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...
Re: proposed javascript refinements
Posted by Paul Lindner <li...@inuus.com>.
Hi Norris, nice to meet you.
We can probably include a binary MPL-licensed version of Rhino with
appropriate attribution. Some of the enterprise people using shindig won't
like it -- they have very picky legal teams. (For example they have an
issue with Juel which implements a JSR, but does not pass the TCK test...)
When and If we move forward we'll get an opinion from the legal-discuss
mailing list for a definitive answer and the proper way forward.
Thanks!
On Tue, Feb 2, 2010 at 4:29 PM, Norris Boyd <no...@google.com> wrote:
> Just to clarify: the issue with Rhino's license under MPL is that there's a
> wish to bundle it in a larger package (Shindig), which is distributed under
> the Apache license, correct?
>
> I read http://apache.org/legal/resolved.html#category-b . Does that
> approach
> not work because you need something more than a binary inclusion of Rhino?
> I'd be happy to work to take patches back into Rhino so that Shindig could
> use a Rhino binary if that would help.
>
> Thanks,
> Norris
>
> On Tue, Feb 2, 2010 at 7:23 PM, John Hjelmstad <fa...@google.com> wrote:
>
> > +Norris Boyd, key author of Rhino, for comment.
> >
> > 2010/2/2 Paul Lindner <li...@inuus.com>
> >
> > 2010/2/1 ๏̯͡๏ Jasvir Nagra <ja...@google.com>
> >>
> >> >
> >> >
> >> > On Tue, Feb 2, 2010 at 2:47 AM, Tim Wintle <tim.wintle@teamrubber.com
> >> >wrote:
> >> >
> >> >> On Mon, 2010-02-01 at 07:10 -0800, Paul Lindner wrote:
> >> >> > Correct, it's included with yui and closure. John was asking if
> the
> >> >> > closure compiler could be used during runtime. That requires
> >> >> > redistributing rhino, etal which is problematic.
> >> >>
> >> >> Yup, I just meant to point out there is the same licensing issue with
> >> >> other javascript compressors (i.e. yui) as it's based off rhino too.
> >> >>
> >> >
> >> > Just to clarify, is the problem with redistributing rhino a question
> of
> >> the
> >> > MPL licence? Note that a slightly modified version of Rhino is
> >> > redistributed with Sun's Java 1.6 onwards.
> >> >
> >>
> >>
> >> MPL, while not optimal can be worked around with extra effort -- please
> >> see
> >> http://apache.org/legal/resolved.html#category-b
> >>
> >> If we can confine rhino usage to build-time only I'd be happier so we
> can
> >> avoid any issues. We shipped a version of rhino for some time and got
> >> dinged for that in incubation.
> >>
> >
> >
>
Re: proposed javascript refinements
Posted by Norris Boyd <no...@google.com>.
Just to clarify: the issue with Rhino's license under MPL is that there's a
wish to bundle it in a larger package (Shindig), which is distributed under
the Apache license, correct?
I read http://apache.org/legal/resolved.html#category-b . Does that approach
not work because you need something more than a binary inclusion of Rhino?
I'd be happy to work to take patches back into Rhino so that Shindig could
use a Rhino binary if that would help.
Thanks,
Norris
On Tue, Feb 2, 2010 at 7:23 PM, John Hjelmstad <fa...@google.com> wrote:
> +Norris Boyd, key author of Rhino, for comment.
>
> 2010/2/2 Paul Lindner <li...@inuus.com>
>
> 2010/2/1 ๏̯͡๏ Jasvir Nagra <ja...@google.com>
>>
>> >
>> >
>> > On Tue, Feb 2, 2010 at 2:47 AM, Tim Wintle <tim.wintle@teamrubber.com
>> >wrote:
>> >
>> >> On Mon, 2010-02-01 at 07:10 -0800, Paul Lindner wrote:
>> >> > Correct, it's included with yui and closure. John was asking if the
>> >> > closure compiler could be used during runtime. That requires
>> >> > redistributing rhino, etal which is problematic.
>> >>
>> >> Yup, I just meant to point out there is the same licensing issue with
>> >> other javascript compressors (i.e. yui) as it's based off rhino too.
>> >>
>> >
>> > Just to clarify, is the problem with redistributing rhino a question of
>> the
>> > MPL licence? Note that a slightly modified version of Rhino is
>> > redistributed with Sun's Java 1.6 onwards.
>> >
>>
>>
>> MPL, while not optimal can be worked around with extra effort -- please
>> see
>> http://apache.org/legal/resolved.html#category-b
>>
>> If we can confine rhino usage to build-time only I'd be happier so we can
>> avoid any issues. We shipped a version of rhino for some time and got
>> dinged for that in incubation.
>>
>
>
Re: proposed javascript refinements
Posted by John Hjelmstad <fa...@google.com>.
+Norris Boyd, key author of Rhino, for comment.
2010/2/2 Paul Lindner <li...@inuus.com>
> 2010/2/1 ๏̯͡๏ Jasvir Nagra <ja...@google.com>
>
> >
> >
> > On Tue, Feb 2, 2010 at 2:47 AM, Tim Wintle <tim.wintle@teamrubber.com
> >wrote:
> >
> >> On Mon, 2010-02-01 at 07:10 -0800, Paul Lindner wrote:
> >> > Correct, it's included with yui and closure. John was asking if the
> >> > closure compiler could be used during runtime. That requires
> >> > redistributing rhino, etal which is problematic.
> >>
> >> Yup, I just meant to point out there is the same licensing issue with
> >> other javascript compressors (i.e. yui) as it's based off rhino too.
> >>
> >
> > Just to clarify, is the problem with redistributing rhino a question of
> the
> > MPL licence? Note that a slightly modified version of Rhino is
> > redistributed with Sun's Java 1.6 onwards.
> >
>
>
> MPL, while not optimal can be worked around with extra effort -- please see
> http://apache.org/legal/resolved.html#category-b
>
> If we can confine rhino usage to build-time only I'd be happier so we can
> avoid any issues. We shipped a version of rhino for some time and got
> dinged for that in incubation.
>
Re: proposed javascript refinements
Posted by Paul Lindner <li...@inuus.com>.
2010/2/1 ๏̯͡๏ Jasvir Nagra <ja...@google.com>
>
>
> On Tue, Feb 2, 2010 at 2:47 AM, Tim Wintle <ti...@teamrubber.com>wrote:
>
>> On Mon, 2010-02-01 at 07:10 -0800, Paul Lindner wrote:
>> > Correct, it's included with yui and closure. John was asking if the
>> > closure compiler could be used during runtime. That requires
>> > redistributing rhino, etal which is problematic.
>>
>> Yup, I just meant to point out there is the same licensing issue with
>> other javascript compressors (i.e. yui) as it's based off rhino too.
>>
>
> Just to clarify, is the problem with redistributing rhino a question of the
> MPL licence? Note that a slightly modified version of Rhino is
> redistributed with Sun's Java 1.6 onwards.
>
MPL, while not optimal can be worked around with extra effort -- please see
http://apache.org/legal/resolved.html#category-b
If we can confine rhino usage to build-time only I'd be happier so we can
avoid any issues. We shipped a version of rhino for some time and got
dinged for that in incubation.
Re: proposed javascript refinements
Posted by ๏̯͡๏ Jasvir Nagra <ja...@google.com>.
On Tue, Feb 2, 2010 at 2:47 AM, Tim Wintle <ti...@teamrubber.com>wrote:
> On Mon, 2010-02-01 at 07:10 -0800, Paul Lindner wrote:
> > Correct, it's included with yui and closure. John was asking if the
> > closure compiler could be used during runtime. That requires
> > redistributing rhino, etal which is problematic.
>
> Yup, I just meant to point out there is the same licensing issue with
> other javascript compressors (i.e. yui) as it's based off rhino too.
>
Just to clarify, is the problem with redistributing rhino a question of the
MPL licence? Note that a slightly modified version of Rhino is
redistributed with Sun's Java 1.6 onwards.
>
> Tim
>
> >
> > On Mon, Feb 1, 2010 at 3:38 AM, Tim Wintle <ti...@teamrubber.com>
> > wrote:
> > On Mon, 2010-02-01 at 01:12 -0800, Paul Lindner wrote:
> > >
> > > 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 I understand it, Rhino is MPL/GPL, and is included in both
> > YuiCompressor and Closure-compiler. (It's definitely been
> > modified in
> > YuiCompressor and so I assume in closure compiler)
> >
> > Tim Wintle
> >
> >
>
>
Re: proposed javascript refinements
Posted by Tim Wintle <ti...@teamrubber.com>.
On Mon, 2010-02-01 at 07:10 -0800, Paul Lindner wrote:
> Correct, it's included with yui and closure. John was asking if the
> closure compiler could be used during runtime. That requires
> redistributing rhino, etal which is problematic.
Yup, I just meant to point out there is the same licensing issue with
other javascript compressors (i.e. yui) as it's based off rhino too.
Tim
>
> On Mon, Feb 1, 2010 at 3:38 AM, Tim Wintle <ti...@teamrubber.com>
> wrote:
> On Mon, 2010-02-01 at 01:12 -0800, Paul Lindner wrote:
> >
> > 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 I understand it, Rhino is MPL/GPL, and is included in both
> YuiCompressor and Closure-compiler. (It's definitely been
> modified in
> YuiCompressor and so I assume in closure compiler)
>
> Tim Wintle
>
>
Re: proposed javascript refinements
Posted by Paul Lindner <li...@inuus.com>.
Correct, it's included with yui and closure. John was asking if the closure
compiler could be used during runtime. That requires redistributing rhino,
etal which is problematic.
On Mon, Feb 1, 2010 at 3:38 AM, Tim Wintle <ti...@teamrubber.com>wrote:
> On Mon, 2010-02-01 at 01:12 -0800, Paul Lindner wrote:
> >
> > 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 I understand it, Rhino is MPL/GPL, and is included in both
> YuiCompressor and Closure-compiler. (It's definitely been modified in
> YuiCompressor and so I assume in closure compiler)
>
> Tim Wintle
>
>
Re: proposed javascript refinements
Posted by Tim Wintle <ti...@teamrubber.com>.
On Mon, 2010-02-01 at 01:12 -0800, Paul Lindner wrote:
>
> 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 I understand it, Rhino is MPL/GPL, and is included in both
YuiCompressor and Closure-compiler. (It's definitely been modified in
YuiCompressor and so I assume in closure compiler)
Tim Wintle
Re: proposed javascript refinements
Posted by Paul Lindner <li...@inuus.com>.
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 <pl...@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.
Re: proposed javascript refinements
Posted by John Hjelmstad <fa...@google.com>.
On Wed, Jan 20, 2010 at 1:11 AM, Paul Lindner <pl...@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.
>
> 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
> core.prefs -> gadgets.Prefs?
>
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?
>
> * 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).
>
> * 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 ;)
--j