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 <li...@inuus.com> on 2010/05/14 02:07:59 UTC
Creating a shindig-extras module
There are some features that are new, experimental and generally not
production ready nor standardized yet. However I'd like to see them checked
in and maintained over time after such time they can graduate to
shindig-gadgets and/or shindig-social-api.
I propose putting these new features in a new package named shindig-extras.
Code will be checked into java/extras and it will support javascript
features and java extensions via Guice multibindings and overrides.
The features I want to move here are:
* javascript features for popular javascript libraries. For example here's
org.jquery.core-1.4.2/feature.xml
<feature>
<name>org.jquery.core-1.4.2</name>
<gadget>
<script src="
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/>
</gadget>
<container>
<script inline="true" src="
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/>
</container>
</feature>
* New Api handlers for "Tokens" and "Apps" -- these will provide a way to
create containers that run on third party web sites.
* Anything else anyone else wants to contribute.
Re: Creating a shindig-extras module
Posted by Paul Lindner <li...@inuus.com>.
The top-level 'extras' directory is now available. It has it's own features
directory, guice module and java classes. More to come...
On Thu, May 13, 2010 at 5:07 PM, Paul Lindner <li...@inuus.com> wrote:
> There are some features that are new, experimental and generally not
> production ready nor standardized yet. However I'd like to see them checked
> in and maintained over time after such time they can graduate to
> shindig-gadgets and/or shindig-social-api.
>
> I propose putting these new features in a new package named shindig-extras.
> Code will be checked into java/extras and it will support javascript
> features and java extensions via Guice multibindings and overrides.
>
> The features I want to move here are:
>
> * javascript features for popular javascript libraries. For example here's
> org.jquery.core-1.4.2/feature.xml
>
> <feature>
> <name>org.jquery.core-1.4.2</name>
> <gadget>
> <script src="
> http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/>
> </gadget>
> <container>
> <script inline="true" src="
> http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/>
> </container>
> </feature>
>
>
> * New Api handlers for "Tokens" and "Apps" -- these will provide a way to
> create containers that run on third party web sites.
>
> * Anything else anyone else wants to contribute.
>
>
Re: Creating a shindig-extras module
Posted by Paul Lindner <pl...@linkedin.com>.
I agree with all of your points below with one small clarification -- If my
gaget calls the raw gadgets.rpc methods it can interact with the container.
In any case moving a module into a Require block also:
1) provides a form of URN for script resources. This can help avoid multiple
inclusion and loads the resource once and only once.
2) Allows 3rd party library to participate as a transitive dependency.
Suppose I wanted to make the tabs module very fancy, I could add jquery-ui
as a dependency and it would just work.
3) Potentially providing namespacing. Right now we have contention for $
etal. It would be beneficial to map each 'Require' to it's namespace ala
goog.require() FB.require() etc. We're pretty close with this already,
core.* maps almost 1:1 with gadgets.*
My original use-case for doing this was prototyping a new container
framework to replace gadgets.js. To make life easy I wanted to use jQuery
(see #2 above). I also wanted to include a single script tag on the page.
Thus moving jQuery into a feature.
2010/5/13 ๏̯͡๏ Jasvir Nagra <ja...@google.com>
> The html parser already parses script tags and so knows the urls of code
> being included. At this point, the rewriter could substitute a
> known-to-cajole version if it cared to and/or inline the script. Is your
> concern that a library like jQuery may have been modified and/or be
> included
> from an unrecognized url and so not be recognized as jQuery? I don't
> really have a problem with the change you're suggesting - I'd just like to
> clarify the the purpose of the <Require> tag.
>
> There are two ways in which <Require> tags are being used currently - as a
> powerbox to expose new functionality from the container to a gadget that
> could not be expressed by the apis that the gadget already has access to;
> and as a convenient alternative to <script> tags that point to a well-known
> library of functions. An example of the former is dynamic-height - a
> gadget
> cannot resize itself without help from the container; and an example of the
> latter is minimessage - it provides a convenient api to do things which the
> gadget has sufficient authority to do already.
>
> The nice thing about allowing the use of the Require tag for both of these
> is:
> * the flexibility of varying its semantics from script tags (in particular
> the mapping from the identifier "org.jquery.core-1.4.2" to actual code
> which
> may a modified jquery core).
> * the declarative syntax also makes it slightly easier for a container to
> know what libraries gadgets are using
> * once gadgets start using the Require to request libraries, the container
> can choose whether to provide a library via taming or cajoling.
>
> The downside is subtle and probably not a real downside. By conflating the
> semantics of Require to provide both a powerbox and convenience apis,
> containers that choose not to grant a convenience api aren't actually
> depriving a gadget of any power at all since the gadget can include the
> same
> API via script inclusion.
>
> On Thu, May 13, 2010 at 5:20 PM, Paul Lindner <pl...@linkedin.com>
> wrote:
>
> > we could offer caja versions of said libraries, plus the js can be
> concat'd
> > with the rest of the payload. Lots of interesting things can fallout
> from
> > this technique.
> >
> > 2010/5/13 ๏̯͡๏ Jasvir Nagra <ja...@google.com>
> >
> > > On Thu, May 13, 2010 at 5:07 PM, Paul Lindner <li...@inuus.com>
> wrote:
> > >
> > > > There are some features that are new, experimental and generally not
> > > > production ready nor standardized yet. However I'd like to see them
> > > > checked
> > > > in and maintained over time after such time they can graduate to
> > > > shindig-gadgets and/or shindig-social-api.
> > > >
> > > > I propose putting these new features in a new package named
> > > shindig-extras.
> > > > Code will be checked into java/extras and it will support javascript
> > > > features and java extensions via Guice multibindings and overrides.
> > > >
> > > > The features I want to move here are:
> > > >
> > > > * javascript features for popular javascript libraries. For example
> > > here's
> > > > org.jquery.core-1.4.2/feature.xml
> > > >
> > >
> > > Why would something like jQuery be a feature requested by a gadget
> rather
> > > than a script the gadget author includes with a script tag?
> > >
> > >
> > > >
> > > > <feature>
> > > > <name>org.jquery.core-1.4.2</name>
> > > > <gadget>
> > > > <script src="
> > > > http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/>
> > > > </gadget>
> > > > <container>
> > > > <script inline="true" src="
> > > > http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/>
> > > > </container>
> > > > </feature>
> > > >
> > > >
> > > > * New Api handlers for "Tokens" and "Apps" -- these will provide a
> way
> > to
> > > > create containers that run on third party web sites.
> > > >
> > > > * Anything else anyone else wants to contribute.
> > > >
> > >
> >
>
Re: Creating a shindig-extras module
Posted by ๏̯͡๏ Jasvir Nagra <ja...@google.com>.
The html parser already parses script tags and so knows the urls of code
being included. At this point, the rewriter could substitute a
known-to-cajole version if it cared to and/or inline the script. Is your
concern that a library like jQuery may have been modified and/or be included
from an unrecognized url and so not be recognized as jQuery? I don't
really have a problem with the change you're suggesting - I'd just like to
clarify the the purpose of the <Require> tag.
There are two ways in which <Require> tags are being used currently - as a
powerbox to expose new functionality from the container to a gadget that
could not be expressed by the apis that the gadget already has access to;
and as a convenient alternative to <script> tags that point to a well-known
library of functions. An example of the former is dynamic-height - a gadget
cannot resize itself without help from the container; and an example of the
latter is minimessage - it provides a convenient api to do things which the
gadget has sufficient authority to do already.
The nice thing about allowing the use of the Require tag for both of these
is:
* the flexibility of varying its semantics from script tags (in particular
the mapping from the identifier "org.jquery.core-1.4.2" to actual code which
may a modified jquery core).
* the declarative syntax also makes it slightly easier for a container to
know what libraries gadgets are using
* once gadgets start using the Require to request libraries, the container
can choose whether to provide a library via taming or cajoling.
The downside is subtle and probably not a real downside. By conflating the
semantics of Require to provide both a powerbox and convenience apis,
containers that choose not to grant a convenience api aren't actually
depriving a gadget of any power at all since the gadget can include the same
API via script inclusion.
On Thu, May 13, 2010 at 5:20 PM, Paul Lindner <pl...@linkedin.com> wrote:
> we could offer caja versions of said libraries, plus the js can be concat'd
> with the rest of the payload. Lots of interesting things can fallout from
> this technique.
>
> 2010/5/13 ๏̯͡๏ Jasvir Nagra <ja...@google.com>
>
> > On Thu, May 13, 2010 at 5:07 PM, Paul Lindner <li...@inuus.com> wrote:
> >
> > > There are some features that are new, experimental and generally not
> > > production ready nor standardized yet. However I'd like to see them
> > > checked
> > > in and maintained over time after such time they can graduate to
> > > shindig-gadgets and/or shindig-social-api.
> > >
> > > I propose putting these new features in a new package named
> > shindig-extras.
> > > Code will be checked into java/extras and it will support javascript
> > > features and java extensions via Guice multibindings and overrides.
> > >
> > > The features I want to move here are:
> > >
> > > * javascript features for popular javascript libraries. For example
> > here's
> > > org.jquery.core-1.4.2/feature.xml
> > >
> >
> > Why would something like jQuery be a feature requested by a gadget rather
> > than a script the gadget author includes with a script tag?
> >
> >
> > >
> > > <feature>
> > > <name>org.jquery.core-1.4.2</name>
> > > <gadget>
> > > <script src="
> > > http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/>
> > > </gadget>
> > > <container>
> > > <script inline="true" src="
> > > http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/>
> > > </container>
> > > </feature>
> > >
> > >
> > > * New Api handlers for "Tokens" and "Apps" -- these will provide a way
> to
> > > create containers that run on third party web sites.
> > >
> > > * Anything else anyone else wants to contribute.
> > >
> >
>
Re: Creating a shindig-extras module
Posted by Paul Lindner <pl...@linkedin.com>.
we could offer caja versions of said libraries, plus the js can be concat'd
with the rest of the payload. Lots of interesting things can fallout from
this technique.
2010/5/13 ๏̯͡๏ Jasvir Nagra <ja...@google.com>
> On Thu, May 13, 2010 at 5:07 PM, Paul Lindner <li...@inuus.com> wrote:
>
> > There are some features that are new, experimental and generally not
> > production ready nor standardized yet. However I'd like to see them
> > checked
> > in and maintained over time after such time they can graduate to
> > shindig-gadgets and/or shindig-social-api.
> >
> > I propose putting these new features in a new package named
> shindig-extras.
> > Code will be checked into java/extras and it will support javascript
> > features and java extensions via Guice multibindings and overrides.
> >
> > The features I want to move here are:
> >
> > * javascript features for popular javascript libraries. For example
> here's
> > org.jquery.core-1.4.2/feature.xml
> >
>
> Why would something like jQuery be a feature requested by a gadget rather
> than a script the gadget author includes with a script tag?
>
>
> >
> > <feature>
> > <name>org.jquery.core-1.4.2</name>
> > <gadget>
> > <script src="
> > http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/>
> > </gadget>
> > <container>
> > <script inline="true" src="
> > http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/>
> > </container>
> > </feature>
> >
> >
> > * New Api handlers for "Tokens" and "Apps" -- these will provide a way to
> > create containers that run on third party web sites.
> >
> > * Anything else anyone else wants to contribute.
> >
>
Re: Creating a shindig-extras module
Posted by ๏̯͡๏ Jasvir Nagra <ja...@google.com>.
On Thu, May 13, 2010 at 5:07 PM, Paul Lindner <li...@inuus.com> wrote:
> There are some features that are new, experimental and generally not
> production ready nor standardized yet. However I'd like to see them
> checked
> in and maintained over time after such time they can graduate to
> shindig-gadgets and/or shindig-social-api.
>
> I propose putting these new features in a new package named shindig-extras.
> Code will be checked into java/extras and it will support javascript
> features and java extensions via Guice multibindings and overrides.
>
> The features I want to move here are:
>
> * javascript features for popular javascript libraries. For example here's
> org.jquery.core-1.4.2/feature.xml
>
Why would something like jQuery be a feature requested by a gadget rather
than a script the gadget author includes with a script tag?
>
> <feature>
> <name>org.jquery.core-1.4.2</name>
> <gadget>
> <script src="
> http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/>
> </gadget>
> <container>
> <script inline="true" src="
> http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/>
> </container>
> </feature>
>
>
> * New Api handlers for "Tokens" and "Apps" -- these will provide a way to
> create containers that run on third party web sites.
>
> * Anything else anyone else wants to contribute.
>