Re: Shindig gadget-and-container framework

[John Hjelmstad <fa...@google.com>]

Sorry for the very-delayed response. Still figured this is worth commenting.

On Wed, May 12, 2010 at 2:01 PM, Paul Lindner <pl...@linkedin.com> wrote:

> On Wed, May 12, 2010 at 11:16 AM, Kam Kasravi <kkasravi@yahoo-inc.com
> >wrote:
>
> > Will this framework be taking advantage of the features framework where
> > views would be appropriately expanded, etc?
> >
>
> Not sure..  John?
>

Kam, can you expand on this? Not sure what exactly is meant by expanding
views, in the context of common container. We do plan to propose a loose
definition of what a container-mediated feature "means" ie. which handlers a
given <Require feature="x"/> expands to and what their semantics are.


>
>
> > Also, has there been any effort to expand gadgets.rpc so that gadget <->
> > gadget or gadget broadcast would allow gadgets
> > to communicate with one another?
> >
>
> There's been some work integrating Shindig with OpenAjax.  That still
> relies
> upon a hub system.  I've been experimenting with pubsub, and it seems to
> work pretty well too.
>

The OpenAjax work is basically a much-improved pubsub feature, and when
fully proposed I suspect will meet most peoples' needs.

Direct gadget <-> gadget communication without the container being aware, on
the other hand, has seen little effort. It's technically not possible for
the most part, since any gadget desiring to communicate with another needs a
way to address it. The container controls this information. (there's a
longer discussion here, but suffice to say that any wily container could
MITM pretty easily; possible exception to carefully-constructed
window.postMessage browsers, but even then I'm dubious).


>
>
>
> > Finally is the new js taking advantage of SES or commonjs to load
> > resources?
> >
> >
> > Can you give us a reference to SES?  I'm not aware of what that is.
>
> commonjs looks interesting.  It's modules concept aligns pretty well with
> what we do with the js features and would be a more portable way of
> annotating dependencies compared to say closure-library.
>