You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shindig.apache.org by "Michael Hermanto (JIRA)" <ji...@apache.org> on 2010/05/19 07:01:48 UTC
[jira] Created: (SHINDIG-1335) Gadget-and-container JS framework
Gadget-and-container JS framework
---------------------------------
Key: SHINDIG-1335
URL: https://issues.apache.org/jira/browse/SHINDIG-1335
Project: Shindig
Issue Type: New Feature
Components: Javascript
Reporter: Michael Hermanto
Copying/pasting email that I sent to shindig-dev@ 1 week ago --
In Google, we've been developing a lightweight gadget-and-container framework, called "common container", to 1) simplify container and gadget integration model, and 2) provide near-zero barrier to entry to become a gadget container. The framework is a combination of JS (which container clients script source) and API RPC endpoints (which provides the JS with runtime metadata/information). Many of the features have been implemented, and are currently being productionized. Several Google containers are busy prototyping (to integrate with common container) with some success and speed.
Meanwhile, there has been an independent community effort to modernize the Shindig container. It has a similar/same set of goals. In the spirit of re-use, we would like to bring non-Google-specific work that we've done in Google to Shindig. Engineers at Google and Paul Lindner have met, discussed and agreed on the motivations and feature sets. Roughly speaking, they are as follow --
1) JS is served via the gadgets server, as a container feature, ie: /gadgets/js/shindig.container?c=1. This will leverage gadget server compilation of JS and management of library dependencies through transitive-closure.
2) Standard JS API to get metadata to render a gadget, ie: /api/rpc?method=gadgets.get.
- API is implemented using an RPC call similar to other APIs (people, activities, etc) in Shindig.
- RPC will return a URL template and gadget metadata, sufficient to generate iframe render URL. Also, the response can be cached by the clientto evaluate URL template with data for subsequent/similar requests (ie: different user preferences) without requiring an HTTP fetch.
- Also need JS API to refresh a security (/OAuth) token, ie: /api/rpc? method=tokens.get. Gadgets requiring tokens, both short- and long-lived, relies on the container to have these primed in a timely fashion.
3) Standard JS API to render/navigate gadget.
- Base API renders into an HTML element, ie: container.navigateGadget(string, Element)
- Ideally support double buffering for switching gadgets views, ie: gadget.views.requestNavigateTo().
- Need a standard "ready-to-draw" RPC callback, when the gadget has finished initial rendering.
- Respects preferred width, height and other gadget-specified metadata used in rendering.
- Need rendering "styles" to show gadget in a modal dialog, show hovering next to an HTML element, etc.
- Need concept of a "primary" gadget on the page. Navigating to this gadget should fire a callback on the parent page to support navigation in the browser bar.
4) All RPC APIs (gadgets, people, activities) should be callable form the container page.
- Likely implementation is an iframe on the domain of the gadget host. Web site calls gadgets.rpc() to iframe and iframe makes XHR to gadget host.
- Gadget render iframe URLs can be enhanced for latency-optimizing features, ie: container can be an RPC hub for gadgets on the page.
- RPC responses can be obtained from pre-loaded/cache metadata for latency improvements.
- Need to flesh out a standard API to redirect to a login page from the 3rd party site.
What's next? Discuss. We would very much like to hear your thoughts. In the next few days, we will prepare common container code base for public viewing, and upon no strong objections, we will send an initial code drop for review, where which we can discuss further in greater technical details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-1335) Gadget-and-container JS framework
Posted by "Michael Hermanto (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Hermanto updated SHINDIG-1335:
--------------------------------------
Attachment: shindig-1335-0
This is the initial code-drop. It is incomplete as is, but compilable and currently used in Google, with shims to augment missing functionalities. These missing functionalities include OSAPI gadget metadata fetch definition and other/more advanced gadget navigation. Comment away.
> Gadget-and-container JS framework
> ---------------------------------
>
> Key: SHINDIG-1335
> URL: https://issues.apache.org/jira/browse/SHINDIG-1335
> Project: Shindig
> Issue Type: New Feature
> Components: Javascript
> Reporter: Michael Hermanto
> Attachments: shindig-1335-0
>
>
> Copying/pasting email that I sent to shindig-dev@ 1 week ago --
> In Google, we've been developing a lightweight gadget-and-container framework, called "common container", to 1) simplify container and gadget integration model, and 2) provide near-zero barrier to entry to become a gadget container. The framework is a combination of JS (which container clients script source) and API RPC endpoints (which provides the JS with runtime metadata/information). Many of the features have been implemented, and are currently being productionized. Several Google containers are busy prototyping (to integrate with common container) with some success and speed.
> Meanwhile, there has been an independent community effort to modernize the Shindig container. It has a similar/same set of goals. In the spirit of re-use, we would like to bring non-Google-specific work that we've done in Google to Shindig. Engineers at Google and Paul Lindner have met, discussed and agreed on the motivations and feature sets. Roughly speaking, they are as follow --
> 1) JS is served via the gadgets server, as a container feature, ie: /gadgets/js/shindig.container?c=1. This will leverage gadget server compilation of JS and management of library dependencies through transitive-closure.
> 2) Standard JS API to get metadata to render a gadget, ie: /api/rpc?method=gadgets.get.
> - API is implemented using an RPC call similar to other APIs (people, activities, etc) in Shindig.
> - RPC will return a URL template and gadget metadata, sufficient to generate iframe render URL. Also, the response can be cached by the clientto evaluate URL template with data for subsequent/similar requests (ie: different user preferences) without requiring an HTTP fetch.
> - Also need JS API to refresh a security (/OAuth) token, ie: /api/rpc? method=tokens.get. Gadgets requiring tokens, both short- and long-lived, relies on the container to have these primed in a timely fashion.
> 3) Standard JS API to render/navigate gadget.
> - Base API renders into an HTML element, ie: container.navigateGadget(string, Element)
> - Ideally support double buffering for switching gadgets views, ie: gadget.views.requestNavigateTo().
> - Need a standard "ready-to-draw" RPC callback, when the gadget has finished initial rendering.
> - Respects preferred width, height and other gadget-specified metadata used in rendering.
> - Need rendering "styles" to show gadget in a modal dialog, show hovering next to an HTML element, etc.
> - Need concept of a "primary" gadget on the page. Navigating to this gadget should fire a callback on the parent page to support navigation in the browser bar.
> 4) All RPC APIs (gadgets, people, activities) should be callable form the container page.
> - Likely implementation is an iframe on the domain of the gadget host. Web site calls gadgets.rpc() to iframe and iframe makes XHR to gadget host.
> - Gadget render iframe URLs can be enhanced for latency-optimizing features, ie: container can be an RPC hub for gadgets on the page.
> - RPC responses can be obtained from pre-loaded/cache metadata for latency improvements.
> - Need to flesh out a standard API to redirect to a login page from the 3rd party site.
> What's next? Discuss. We would very much like to hear your thoughts. In the next few days, we will prepare common container code base for public viewing, and upon no strong objections, we will send an initial code drop for review, where which we can discuss further in greater technical details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-1335) Gadget-and-container JS framework
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871280#action_12871280 ]
Paul Lindner commented on SHINDIG-1335:
---------------------------------------
If/when this is expanded to use an 'apps' service then we can have default code that sends pings to backends when a user installs/removes an application (or any other event for that matter).
Just need to get the SocialSite code ported over :)
> Gadget-and-container JS framework
> ---------------------------------
>
> Key: SHINDIG-1335
> URL: https://issues.apache.org/jira/browse/SHINDIG-1335
> Project: Shindig
> Issue Type: New Feature
> Components: Javascript
> Reporter: Michael Hermanto
> Attachments: shindig-1335-0
>
>
> Copying/pasting email that I sent to shindig-dev@ 1 week ago --
> In Google, we've been developing a lightweight gadget-and-container framework, called "common container", to 1) simplify container and gadget integration model, and 2) provide near-zero barrier to entry to become a gadget container. The framework is a combination of JS (which container clients script source) and API RPC endpoints (which provides the JS with runtime metadata/information). Many of the features have been implemented, and are currently being productionized. Several Google containers are busy prototyping (to integrate with common container) with some success and speed.
> Meanwhile, there has been an independent community effort to modernize the Shindig container. It has a similar/same set of goals. In the spirit of re-use, we would like to bring non-Google-specific work that we've done in Google to Shindig. Engineers at Google and Paul Lindner have met, discussed and agreed on the motivations and feature sets. Roughly speaking, they are as follow --
> 1) JS is served via the gadgets server, as a container feature, ie: /gadgets/js/shindig.container?c=1. This will leverage gadget server compilation of JS and management of library dependencies through transitive-closure.
> 2) Standard JS API to get metadata to render a gadget, ie: /api/rpc?method=gadgets.get.
> - API is implemented using an RPC call similar to other APIs (people, activities, etc) in Shindig.
> - RPC will return a URL template and gadget metadata, sufficient to generate iframe render URL. Also, the response can be cached by the clientto evaluate URL template with data for subsequent/similar requests (ie: different user preferences) without requiring an HTTP fetch.
> - Also need JS API to refresh a security (/OAuth) token, ie: /api/rpc? method=tokens.get. Gadgets requiring tokens, both short- and long-lived, relies on the container to have these primed in a timely fashion.
> 3) Standard JS API to render/navigate gadget.
> - Base API renders into an HTML element, ie: container.navigateGadget(string, Element)
> - Ideally support double buffering for switching gadgets views, ie: gadget.views.requestNavigateTo().
> - Need a standard "ready-to-draw" RPC callback, when the gadget has finished initial rendering.
> - Respects preferred width, height and other gadget-specified metadata used in rendering.
> - Need rendering "styles" to show gadget in a modal dialog, show hovering next to an HTML element, etc.
> - Need concept of a "primary" gadget on the page. Navigating to this gadget should fire a callback on the parent page to support navigation in the browser bar.
> 4) All RPC APIs (gadgets, people, activities) should be callable form the container page.
> - Likely implementation is an iframe on the domain of the gadget host. Web site calls gadgets.rpc() to iframe and iframe makes XHR to gadget host.
> - Gadget render iframe URLs can be enhanced for latency-optimizing features, ie: container can be an RPC hub for gadgets on the page.
> - RPC responses can be obtained from pre-loaded/cache metadata for latency improvements.
> - Need to flesh out a standard API to redirect to a login page from the 3rd party site.
> What's next? Discuss. We would very much like to hear your thoughts. In the next few days, we will prepare common container code base for public viewing, and upon no strong objections, we will send an initial code drop for review, where which we can discuss further in greater technical details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SHINDIG-1335) Gadget-and-container JS framework
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Lindner resolved SHINDIG-1335.
-----------------------------------
Fix Version/s: 2.0.0-RC1
Resolution: Fixed
committed. Now to get working samples with this :)
> Gadget-and-container JS framework
> ---------------------------------
>
> Key: SHINDIG-1335
> URL: https://issues.apache.org/jira/browse/SHINDIG-1335
> Project: Shindig
> Issue Type: New Feature
> Components: Javascript
> Reporter: Michael Hermanto
> Fix For: 2.0.0-RC1
>
> Attachments: shindig-1335-0
>
>
> Copying/pasting email that I sent to shindig-dev@ 1 week ago --
> In Google, we've been developing a lightweight gadget-and-container framework, called "common container", to 1) simplify container and gadget integration model, and 2) provide near-zero barrier to entry to become a gadget container. The framework is a combination of JS (which container clients script source) and API RPC endpoints (which provides the JS with runtime metadata/information). Many of the features have been implemented, and are currently being productionized. Several Google containers are busy prototyping (to integrate with common container) with some success and speed.
> Meanwhile, there has been an independent community effort to modernize the Shindig container. It has a similar/same set of goals. In the spirit of re-use, we would like to bring non-Google-specific work that we've done in Google to Shindig. Engineers at Google and Paul Lindner have met, discussed and agreed on the motivations and feature sets. Roughly speaking, they are as follow --
> 1) JS is served via the gadgets server, as a container feature, ie: /gadgets/js/shindig.container?c=1. This will leverage gadget server compilation of JS and management of library dependencies through transitive-closure.
> 2) Standard JS API to get metadata to render a gadget, ie: /api/rpc?method=gadgets.get.
> - API is implemented using an RPC call similar to other APIs (people, activities, etc) in Shindig.
> - RPC will return a URL template and gadget metadata, sufficient to generate iframe render URL. Also, the response can be cached by the clientto evaluate URL template with data for subsequent/similar requests (ie: different user preferences) without requiring an HTTP fetch.
> - Also need JS API to refresh a security (/OAuth) token, ie: /api/rpc? method=tokens.get. Gadgets requiring tokens, both short- and long-lived, relies on the container to have these primed in a timely fashion.
> 3) Standard JS API to render/navigate gadget.
> - Base API renders into an HTML element, ie: container.navigateGadget(string, Element)
> - Ideally support double buffering for switching gadgets views, ie: gadget.views.requestNavigateTo().
> - Need a standard "ready-to-draw" RPC callback, when the gadget has finished initial rendering.
> - Respects preferred width, height and other gadget-specified metadata used in rendering.
> - Need rendering "styles" to show gadget in a modal dialog, show hovering next to an HTML element, etc.
> - Need concept of a "primary" gadget on the page. Navigating to this gadget should fire a callback on the parent page to support navigation in the browser bar.
> 4) All RPC APIs (gadgets, people, activities) should be callable form the container page.
> - Likely implementation is an iframe on the domain of the gadget host. Web site calls gadgets.rpc() to iframe and iframe makes XHR to gadget host.
> - Gadget render iframe URLs can be enhanced for latency-optimizing features, ie: container can be an RPC hub for gadgets on the page.
> - RPC responses can be obtained from pre-loaded/cache metadata for latency improvements.
> - Need to flesh out a standard API to redirect to a login page from the 3rd party site.
> What's next? Discuss. We would very much like to hear your thoughts. In the next few days, we will prepare common container code base for public viewing, and upon no strong objections, we will send an initial code drop for review, where which we can discuss further in greater technical details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-1335) Gadget-and-container JS framework
Posted by "Michael Hermanto (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868995#action_12868995 ]
Michael Hermanto commented on SHINDIG-1335:
-------------------------------------------
Code uploaded to http://codereview.appspot.com/1218045/show
> Gadget-and-container JS framework
> ---------------------------------
>
> Key: SHINDIG-1335
> URL: https://issues.apache.org/jira/browse/SHINDIG-1335
> Project: Shindig
> Issue Type: New Feature
> Components: Javascript
> Reporter: Michael Hermanto
> Attachments: shindig-1335-0
>
>
> Copying/pasting email that I sent to shindig-dev@ 1 week ago --
> In Google, we've been developing a lightweight gadget-and-container framework, called "common container", to 1) simplify container and gadget integration model, and 2) provide near-zero barrier to entry to become a gadget container. The framework is a combination of JS (which container clients script source) and API RPC endpoints (which provides the JS with runtime metadata/information). Many of the features have been implemented, and are currently being productionized. Several Google containers are busy prototyping (to integrate with common container) with some success and speed.
> Meanwhile, there has been an independent community effort to modernize the Shindig container. It has a similar/same set of goals. In the spirit of re-use, we would like to bring non-Google-specific work that we've done in Google to Shindig. Engineers at Google and Paul Lindner have met, discussed and agreed on the motivations and feature sets. Roughly speaking, they are as follow --
> 1) JS is served via the gadgets server, as a container feature, ie: /gadgets/js/shindig.container?c=1. This will leverage gadget server compilation of JS and management of library dependencies through transitive-closure.
> 2) Standard JS API to get metadata to render a gadget, ie: /api/rpc?method=gadgets.get.
> - API is implemented using an RPC call similar to other APIs (people, activities, etc) in Shindig.
> - RPC will return a URL template and gadget metadata, sufficient to generate iframe render URL. Also, the response can be cached by the clientto evaluate URL template with data for subsequent/similar requests (ie: different user preferences) without requiring an HTTP fetch.
> - Also need JS API to refresh a security (/OAuth) token, ie: /api/rpc? method=tokens.get. Gadgets requiring tokens, both short- and long-lived, relies on the container to have these primed in a timely fashion.
> 3) Standard JS API to render/navigate gadget.
> - Base API renders into an HTML element, ie: container.navigateGadget(string, Element)
> - Ideally support double buffering for switching gadgets views, ie: gadget.views.requestNavigateTo().
> - Need a standard "ready-to-draw" RPC callback, when the gadget has finished initial rendering.
> - Respects preferred width, height and other gadget-specified metadata used in rendering.
> - Need rendering "styles" to show gadget in a modal dialog, show hovering next to an HTML element, etc.
> - Need concept of a "primary" gadget on the page. Navigating to this gadget should fire a callback on the parent page to support navigation in the browser bar.
> 4) All RPC APIs (gadgets, people, activities) should be callable form the container page.
> - Likely implementation is an iframe on the domain of the gadget host. Web site calls gadgets.rpc() to iframe and iframe makes XHR to gadget host.
> - Gadget render iframe URLs can be enhanced for latency-optimizing features, ie: container can be an RPC hub for gadgets on the page.
> - RPC responses can be obtained from pre-loaded/cache metadata for latency improvements.
> - Need to flesh out a standard API to redirect to a login page from the 3rd party site.
> What's next? Discuss. We would very much like to hear your thoughts. In the next few days, we will prepare common container code base for public viewing, and upon no strong objections, we will send an initial code drop for review, where which we can discuss further in greater technical details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-1335) Gadget-and-container JS framework
Posted by "Mark Weitzel (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871189#action_12871189 ]
Mark Weitzel commented on SHINDIG-1335:
---------------------------------------
Does this contain the code for the gadget life cycle events that are defined in the specification? We could easily stub out the services on the back end to simply print to the console or something like that. It would be good to provide this so that other containers can start supporting these events in a consistent way.
> Gadget-and-container JS framework
> ---------------------------------
>
> Key: SHINDIG-1335
> URL: https://issues.apache.org/jira/browse/SHINDIG-1335
> Project: Shindig
> Issue Type: New Feature
> Components: Javascript
> Reporter: Michael Hermanto
> Attachments: shindig-1335-0
>
>
> Copying/pasting email that I sent to shindig-dev@ 1 week ago --
> In Google, we've been developing a lightweight gadget-and-container framework, called "common container", to 1) simplify container and gadget integration model, and 2) provide near-zero barrier to entry to become a gadget container. The framework is a combination of JS (which container clients script source) and API RPC endpoints (which provides the JS with runtime metadata/information). Many of the features have been implemented, and are currently being productionized. Several Google containers are busy prototyping (to integrate with common container) with some success and speed.
> Meanwhile, there has been an independent community effort to modernize the Shindig container. It has a similar/same set of goals. In the spirit of re-use, we would like to bring non-Google-specific work that we've done in Google to Shindig. Engineers at Google and Paul Lindner have met, discussed and agreed on the motivations and feature sets. Roughly speaking, they are as follow --
> 1) JS is served via the gadgets server, as a container feature, ie: /gadgets/js/shindig.container?c=1. This will leverage gadget server compilation of JS and management of library dependencies through transitive-closure.
> 2) Standard JS API to get metadata to render a gadget, ie: /api/rpc?method=gadgets.get.
> - API is implemented using an RPC call similar to other APIs (people, activities, etc) in Shindig.
> - RPC will return a URL template and gadget metadata, sufficient to generate iframe render URL. Also, the response can be cached by the clientto evaluate URL template with data for subsequent/similar requests (ie: different user preferences) without requiring an HTTP fetch.
> - Also need JS API to refresh a security (/OAuth) token, ie: /api/rpc? method=tokens.get. Gadgets requiring tokens, both short- and long-lived, relies on the container to have these primed in a timely fashion.
> 3) Standard JS API to render/navigate gadget.
> - Base API renders into an HTML element, ie: container.navigateGadget(string, Element)
> - Ideally support double buffering for switching gadgets views, ie: gadget.views.requestNavigateTo().
> - Need a standard "ready-to-draw" RPC callback, when the gadget has finished initial rendering.
> - Respects preferred width, height and other gadget-specified metadata used in rendering.
> - Need rendering "styles" to show gadget in a modal dialog, show hovering next to an HTML element, etc.
> - Need concept of a "primary" gadget on the page. Navigating to this gadget should fire a callback on the parent page to support navigation in the browser bar.
> 4) All RPC APIs (gadgets, people, activities) should be callable form the container page.
> - Likely implementation is an iframe on the domain of the gadget host. Web site calls gadgets.rpc() to iframe and iframe makes XHR to gadget host.
> - Gadget render iframe URLs can be enhanced for latency-optimizing features, ie: container can be an RPC hub for gadgets on the page.
> - RPC responses can be obtained from pre-loaded/cache metadata for latency improvements.
> - Need to flesh out a standard API to redirect to a login page from the 3rd party site.
> What's next? Discuss. We would very much like to hear your thoughts. In the next few days, we will prepare common container code base for public viewing, and upon no strong objections, we will send an initial code drop for review, where which we can discuss further in greater technical details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.