OpenSocial in the Enterprise: Connecting Apps with Gadgets
1. OpenSocial
in the
Enterprise
Tim Moore
Atlassian Developer
2. Atlassian
8 products • 15,000 customers • 113 countries
Collaboration Tools Development Tools
Confluence JIRA
Largest enterprise wiki FishEye, Crucible, Bamboo,
Clover, IDE Connectors
36. Anatomy of a Gadget
• XML Spec File
• Metadata, HTML Content, and JavaScript
37. Anatomy of a Gadget
• XML Spec File
• Metadata, HTML Content, and JavaScript
• Core JavaScript API
• Access Preferences, Make Requests
38. Anatomy of a Gadget
• XML Spec File
• Metadata, HTML Content, and JavaScript
• Core JavaScript API
• Access Preferences, Make Requests
• Gadget Features
• Additional, Optional Capabilities & APIs
49. JavaScript
// Create minimessage factory
var msg = new gadgets.MiniMessage();
// Show a small loading message to the user
var loadMessage = msg.createStaticMessage("loading...");
// Get configured user prefs
var prefs = new gadgets.Prefs();
var showDate = prefs.getBool("show_date");
var showSummary = prefs.getBool("show_summ");
var numEntries = prefs.getInt("num_entries");
// Fetch issues when the gadget loads
gadgets.util.registerOnLoadHandler(fetchIssues);
50. JavaScript
// Create minimessage factory
var msg = new gadgets.MiniMessage();
// Show a small loading message to the user
var loadMessage = msg.createStaticMessage("loading...");
// Get configured user prefs
var prefs = new gadgets.Prefs();
var showDate = prefs.getBool("show_date");
var showSummary = prefs.getBool("show_summ");
var numEntries = prefs.getInt("num_entries");
// Fetch issues when the gadget loads
gadgets.util.registerOnLoadHandler(fetchIssues);
51. JavaScript
// Create minimessage factory
var msg = new gadgets.MiniMessage();
// Show a small loading message to the user
var loadMessage = msg.createStaticMessage("loading...");
// Get configured user prefs
var prefs = new gadgets.Prefs();
var showDate = prefs.getBool("show_date");
var showSummary = prefs.getBool("show_summ");
var numEntries = prefs.getInt("num_entries");
// Fetch issues when the gadget loads
gadgets.util.registerOnLoadHandler(fetchIssues);
• Atlassian makes development and collaboration tools
• HQ in Sydney, Australia, with offices in SF & Amsterdam
• At Atlassian since October 2007
• Developer in the San Francisco office
• Started project to build a new Atlassian Dashboard component last July
• I’ll talk about:
• Why we made it
• How we made it
• Why we chose OpenSocial gadgets
• How OpenSocial gadgets work
• Some challenges we faced
• Future directions for OpenSocial
• Our flagship product, JIRA has had a customizable dashboard since 2003
• We wanted to reinvent JIRA’s dashboard for version 4.0
• All Atlassian products have dashboards
• None have the flexibility or extensibility of JIRA’s
• We wanted a dashboard component independent from JIRA, could be added to all of the products
• Beyond dashboard in every app, combine information from different apps in one place
• All Atlassian products have dashboards
• None have the flexibility or extensibility of JIRA’s
• We wanted a dashboard component independent from JIRA, could be added to all of the products
• Beyond dashboard in every app, combine information from different apps in one place
• All Atlassian products have dashboards
• None have the flexibility or extensibility of JIRA’s
• We wanted a dashboard component independent from JIRA, could be added to all of the products
• Beyond dashboard in every app, combine information from different apps in one place
• All Atlassian products have dashboards
• None have the flexibility or extensibility of JIRA’s
• We wanted a dashboard component independent from JIRA, could be added to all of the products
• Beyond dashboard in every app, combine information from different apps in one place
• All Atlassian products have dashboards
• None have the flexibility or extensibility of JIRA’s
• We wanted a dashboard component independent from JIRA, could be added to all of the products
• Beyond dashboard in every app, combine information from different apps in one place
• Not just cross-app, but cross-instance
• Could be gadgets from multiple installations of JIRA
• Not just cross-Atlassian-app, either…
• Intended to enable improved integration with other applications
• Most companies use a variety of tools from a variety of vendors
• Make it easier to show info from these sys w/ issues, doc, and source code
• Prev. attempts to integrate resulted in compatibility issues
• JIRA FishEye plugin had to be revised due to changes in JIRA or in FishEye
&#x2022; Broader view: emphasize <click> teams, <click> projects, <click> tasks over tools
&#x2022; See how a project is going, by looking at project dashboard
&#x2022; Not checking a dozen different dashboards for tools that the project team happens to use
&#x2022; We discovered that a technology that was intended for a very different purpose is actually ideally suited to solve these problems.
&#x2022; Broader view: emphasize <click> teams, <click> projects, <click> tasks over tools
&#x2022; See how a project is going, by looking at project dashboard
&#x2022; Not checking a dozen different dashboards for tools that the project team happens to use
&#x2022; We discovered that a technology that was intended for a very different purpose is actually ideally suited to solve these problems.
&#x2022; Broader view: emphasize <click> teams, <click> projects, <click> tasks over tools
&#x2022; See how a project is going, by looking at project dashboard
&#x2022; Not checking a dozen different dashboards for tools that the project team happens to use
&#x2022; We discovered that a technology that was intended for a very different purpose is actually ideally suited to solve these problems.
&#x2022; Broader view: emphasize <click> teams, <click> projects, <click> tasks over tools
&#x2022; See how a project is going, by looking at project dashboard
&#x2022; Not checking a dozen different dashboards for tools that the project team happens to use
&#x2022; We discovered that a technology that was intended for a very different purpose is actually ideally suited to solve these problems.
&#x2022; Broader view: emphasize <click> teams, <click> projects, <click> tasks over tools
&#x2022; See how a project is going, by looking at project dashboard
&#x2022; Not checking a dozen different dashboards for tools that the project team happens to use
&#x2022; We discovered that a technology that was intended for a very different purpose is actually ideally suited to solve these problems.
&#x2022; Broader view: emphasize <click> teams, <click> projects, <click> tasks over tools
&#x2022; See how a project is going, by looking at project dashboard
&#x2022; Not checking a dozen different dashboards for tools that the project team happens to use
&#x2022; We discovered that a technology that was intended for a very different purpose is actually ideally suited to solve these problems.
&#x2022; The solution we found was part of the OpenSocial standard
&#x2022; OpenSocial: Emerging technology intended to provide a standard way to share social data across the web
&#x2022; Created to be a more open alternative to Facebook applications.
&#x2022; Published as an open standard
&#x2022; Participation from community members representing
&#x2022; Social networks
&#x2022; &#x201C;Portal&#x201D; sites
&#x2022; Enterprise applications
&#x2022; Open source applications
&#x2022; Participation is open to anyone
&#x2022; Three main components&#x2026;
&#x2022; Social data model
&#x2022; Standard way to describe people, relationships, activity, and other info commonly found in social websites
&#x2022; Web service APIs for accessing that social data
&#x2022; REST and RPC versions
&#x2022; Representations of that data as XML, JSON, and Atom.
&#x2022; OpenSocial Gadgets specification &#x2014;&#xA0;the part we&#x2019;re using
&#x2022; Gadgets are web-based components, or mini-applications, based on HTML, CSS, & JavaScript
&#x2022; Published from one site, displayed on others &#x2014; called &#x201C;containers&#x201D;
&#x2022; Different contexts that it doesn&#x2019;t need to be aware of
&#x2022; Dashboard like JIRA&#x2019;s
&#x2022; User profile page
&#x2022; Blog sidebar
&#x2022; Isolated from one another and from the container using iframes
&#x2022; Can communicate using well-defined, safe channels
&#x2022; OpenSocial Gadgets: standardized derivative of iGoogle Gadgets
&#x2022; Extensible dashboard
&#x2022; Allows you to syndicate content from all over the internet and display it in one place
&#x2022; Based on simple, standard web technologies
&#x2022; No Java needed in many cases
&#x2022; Gadgets are protected from each other
&#x2022; Sandboxed in iframes
&#x2022; Avoids problems with markup, scripts, exceptions, slow performance
&#x2022; Gadgets can be displayed in different contexts
&#x2022; Can be displayed in other containers, such as iGoogle or Gmail
&#x2022; Based on simple, standard web technologies
&#x2022; No Java needed in many cases
&#x2022; Gadgets are protected from each other
&#x2022; Sandboxed in iframes
&#x2022; Avoids problems with markup, scripts, exceptions, slow performance
&#x2022; Gadgets can be displayed in different contexts
&#x2022; Can be displayed in other containers, such as iGoogle or Gmail
&#x2022; Based on simple, standard web technologies
&#x2022; No Java needed in many cases
&#x2022; Gadgets are protected from each other
&#x2022; Sandboxed in iframes
&#x2022; Avoids problems with markup, scripts, exceptions, slow performance
&#x2022; Gadgets can be displayed in different contexts
&#x2022; Can be displayed in other containers, such as iGoogle or Gmail
&#x2022; Designed & built for sharing content between heterogenous apps
&#x2022; This is exactly what it&#x2019;s used for in iGoogle, and exactly what it&#x2019;s used for in OpenSocial
&#x2022; Open standard
&#x2022; Based on other emerging standards
&#x2022; Portable Contacts
&#x2022; OAuth
&#x2022; Basic web technology like HTML, CSS, & JavaScript
&#x2022; Substantial industry support
&#x2022; Social networks
&#x2022; Increasingly, among business and enterprise-oriented vendors
&#x2022; These are the better-known companies, but the list keeps growing
&#x2022; Also support from the open source world
&#x2022; Apache Shindig is the open-source reference implementation of the OpenSocial standard.
&#x2022; Comes in PHP & Java versions.
&#x2022; Part of the Apache project
&#x2022; Friendly license for commercial software
&#x2022; Contributed by Google from the same code that runs iGoogle
&#x2022; Already being used in production by most OpenSocial containers
&#x2022; OpenSocial Gadgets spec defines three main parts
&#x2022; <click> XML spec file: description of everything that makes up your gadget
&#x2022; Metadata, such as the title & directory information
&#x2022; Content that fills the gadget iframe
&#x2022; Can be hosted on any web server
&#x2022; Gadget containers can be configured with a list of gadget spec URLs
&#x2022; Fetch the gadget spec XML to render or display in the directory
&#x2022; To avoid too much HTTP traffic, containers cache specs
&#x2022; Spec file needs to be more or less static
&#x2022; If it changes on each request, users won&#x2019;t see those changes
&#x2022; To make the gadget do something interesting, use JavaScript
&#x2022; Inline or with a link to an external script file
&#x2022; <click> JavaScript makes use of the core gadgets JavaScript API
&#x2022; Automatically made available to all gadgets
&#x2022; Access configurable preferences
&#x2022; Make requests to web services
&#x2022; <click> Features: gadgets can use them by declaring them in spec
&#x2022; Additional capabilities for gadgets
&#x2022; Often new APIs that the gadget can call in its JavaScript code
&#x2022; Can provide UI features: tabs or banners
&#x2022; Can provide container integration features: resizing or renaming
&#x2022; Some are defined in the spec, but may not be provided by all containers, others are container specific
&#x2022; We use a custom feature to let us know which directory categories a gadget should be included in
&#x2022; Gadgets can decide to require the feature
&#x2022; Won&#x2019;t work in containers that don&#x2019;t provide it
&#x2022; Or make it optional
&#x2022; Gadget must test for feature before using it
&#x2022; OpenSocial Gadgets spec defines three main parts
&#x2022; <click> XML spec file: description of everything that makes up your gadget
&#x2022; Metadata, such as the title & directory information
&#x2022; Content that fills the gadget iframe
&#x2022; Can be hosted on any web server
&#x2022; Gadget containers can be configured with a list of gadget spec URLs
&#x2022; Fetch the gadget spec XML to render or display in the directory
&#x2022; To avoid too much HTTP traffic, containers cache specs
&#x2022; Spec file needs to be more or less static
&#x2022; If it changes on each request, users won&#x2019;t see those changes
&#x2022; To make the gadget do something interesting, use JavaScript
&#x2022; Inline or with a link to an external script file
&#x2022; <click> JavaScript makes use of the core gadgets JavaScript API
&#x2022; Automatically made available to all gadgets
&#x2022; Access configurable preferences
&#x2022; Make requests to web services
&#x2022; <click> Features: gadgets can use them by declaring them in spec
&#x2022; Additional capabilities for gadgets
&#x2022; Often new APIs that the gadget can call in its JavaScript code
&#x2022; Can provide UI features: tabs or banners
&#x2022; Can provide container integration features: resizing or renaming
&#x2022; Some are defined in the spec, but may not be provided by all containers, others are container specific
&#x2022; We use a custom feature to let us know which directory categories a gadget should be included in
&#x2022; Gadgets can decide to require the feature
&#x2022; Won&#x2019;t work in containers that don&#x2019;t provide it
&#x2022; Or make it optional
&#x2022; Gadget must test for feature before using it
&#x2022; OpenSocial Gadgets spec defines three main parts
&#x2022; <click> XML spec file: description of everything that makes up your gadget
&#x2022; Metadata, such as the title & directory information
&#x2022; Content that fills the gadget iframe
&#x2022; Can be hosted on any web server
&#x2022; Gadget containers can be configured with a list of gadget spec URLs
&#x2022; Fetch the gadget spec XML to render or display in the directory
&#x2022; To avoid too much HTTP traffic, containers cache specs
&#x2022; Spec file needs to be more or less static
&#x2022; If it changes on each request, users won&#x2019;t see those changes
&#x2022; To make the gadget do something interesting, use JavaScript
&#x2022; Inline or with a link to an external script file
&#x2022; <click> JavaScript makes use of the core gadgets JavaScript API
&#x2022; Automatically made available to all gadgets
&#x2022; Access configurable preferences
&#x2022; Make requests to web services
&#x2022; <click> Features: gadgets can use them by declaring them in spec
&#x2022; Additional capabilities for gadgets
&#x2022; Often new APIs that the gadget can call in its JavaScript code
&#x2022; Can provide UI features: tabs or banners
&#x2022; Can provide container integration features: resizing or renaming
&#x2022; Some are defined in the spec, but may not be provided by all containers, others are container specific
&#x2022; We use a custom feature to let us know which directory categories a gadget should be included in
&#x2022; Gadgets can decide to require the feature
&#x2022; Won&#x2019;t work in containers that don&#x2019;t provide it
&#x2022; Or make it optional
&#x2022; Gadget must test for feature before using it
&#x2022; XML spec file in more detail
&#x2022; Gadget that loads a issues from JIRA and displays them in a list
&#x2022; Simple, but gives a good overview of how to write a gadget
&#x2022; I&#x2019;ll go through it one section at a time
&#x2022; XML Banner.
&#x2022; <Module> Element. This is the root element for a gadget.
&#x2022; <ModulePrefs> Element. This is where gadget metadata goes.
&#x2022; Attributes are for directory and title bar <click>
&#x2022; <Require> elements declare features that this gadget needs to use
&#x2022; minimessage: simple API for displaying a brief message in the gadget
&#x2022; We&#x2019;ll use it to display a &#x201C;loading&#x201D; message
&#x2022; dynamic-height: allows the gadget to resize itself
&#x2022; We&#x2019;ll use this after loading issues to adjust the height of the gadget to fit the list
&#x2022; XML Banner.
&#x2022; <Module> Element. This is the root element for a gadget.
&#x2022; <ModulePrefs> Element. This is where gadget metadata goes.
&#x2022; Attributes are for directory and title bar <click>
&#x2022; <Require> elements declare features that this gadget needs to use
&#x2022; minimessage: simple API for displaying a brief message in the gadget
&#x2022; We&#x2019;ll use it to display a &#x201C;loading&#x201D; message
&#x2022; dynamic-height: allows the gadget to resize itself
&#x2022; We&#x2019;ll use this after loading issues to adjust the height of the gadget to fit the list
&#x2022; XML Banner.
&#x2022; <Module> Element. This is the root element for a gadget.
&#x2022; <ModulePrefs> Element. This is where gadget metadata goes.
&#x2022; Attributes are for directory and title bar <click>
&#x2022; <Require> elements declare features that this gadget needs to use
&#x2022; minimessage: simple API for displaying a brief message in the gadget
&#x2022; We&#x2019;ll use it to display a &#x201C;loading&#x201D; message
&#x2022; dynamic-height: allows the gadget to resize itself
&#x2022; We&#x2019;ll use this after loading issues to adjust the height of the gadget to fit the list
&#x2022; XML Banner.
&#x2022; <Module> Element. This is the root element for a gadget.
&#x2022; <ModulePrefs> Element. This is where gadget metadata goes.
&#x2022; Attributes are for directory and title bar <click>
&#x2022; <Require> elements declare features that this gadget needs to use
&#x2022; minimessage: simple API for displaying a brief message in the gadget
&#x2022; We&#x2019;ll use it to display a &#x201C;loading&#x201D; message
&#x2022; dynamic-height: allows the gadget to resize itself
&#x2022; We&#x2019;ll use this after loading issues to adjust the height of the gadget to fit the list
&#x2022; XML Banner.
&#x2022; <Module> Element. This is the root element for a gadget.
&#x2022; <ModulePrefs> Element. This is where gadget metadata goes.
&#x2022; Attributes are for directory and title bar <click>
&#x2022; <Require> elements declare features that this gadget needs to use
&#x2022; minimessage: simple API for displaying a brief message in the gadget
&#x2022; We&#x2019;ll use it to display a &#x201C;loading&#x201D; message
&#x2022; dynamic-height: allows the gadget to resize itself
&#x2022; We&#x2019;ll use this after loading issues to adjust the height of the gadget to fit the list
&#x2022; Simple configuration parameters
&#x2022; Allow the user to customize the gadget&#x2019;s appearance or behavior
&#x2022; Framework automatically generates a configuration UI <click>
&#x2022; Access through the gadget drop-down menu by choosing &#x201C;Edit&#x201D;
&#x2022; Simple configuration parameters
&#x2022; Allow the user to customize the gadget&#x2019;s appearance or behavior
&#x2022; Framework automatically generates a configuration UI <click>
&#x2022; Access through the gadget drop-down menu by choosing &#x201C;Edit&#x201D;
&#x2022; Describes the content of the gadget iframe.
&#x2022; Wrap everything with a CDATA section
&#x2022; Tells XML processors to automatically escape everything within that block
&#x2022; Otherwise, the parser would try to parse the embedded HTML as XML
&#x2022; Link to an external stylesheet
&#x2022; Empty DIV &#x2014; this is where we&#x2019;re going to insert the issues that are loaded from JIRA
&#x2022; External JavaScript file
&#x2022; Script file is where the interesting stuff happens
&#x2022; Uses minimessage to create a loading message <click>
&#x2022; Uses core preference API to fetch the current values of each pref
&#x2022; Uses a core gadget API to register an on-load handler
&#x2022; Passing the name of a function defined later on in the script
&#x2022; Uses minimessage to create a loading message <click>
&#x2022; Uses core preference API to fetch the current values of each pref
&#x2022; Uses a core gadget API to register an on-load handler
&#x2022; Passing the name of a function defined later on in the script
&#x2022; Uses minimessage to create a loading message <click>
&#x2022; Uses core preference API to fetch the current values of each pref
&#x2022; Uses a core gadget API to register an on-load handler
&#x2022; Passing the name of a function defined later on in the script
&#x2022; <click> Gadgets make AJAX requests to retrieve data
&#x2022; JavaScript DOM manipulation to display it
&#x2022; <click> Cross-domain restrictions require the use of a proxy
&#x2022; OpenSocial containers include a request proxy
&#x2022; Allows gadgets to make AJAX requests to web services on other hosts
&#x2022; Proxy requires server-to-server authorization.
&#x2022; Can&#x2019;t use cookies, due to cross-domain restrictions
&#x2022; OAuth is the authorization solution built into OpenSocial
&#x2022; Open standard independent of OpenSocial
&#x2022; Used by Twitter, Photobucket, TripIt, many more
&#x2022; Allows secure communication between gadget request proxy and web services that gadgets call
&#x2022; Doesn&#x2019;t require container to have username and password
&#x2022; Instead, user is directed to the application that the gadget is trying to contact, and asked to authorize the gadget
&#x2022; Like using a Facebook app or Facebook Connect
&#x2022; If this all sounds kind of complicated, it is
&#x2022; The gadgets core API provides a function that makes it easy
&#x2022; <click> Gadgets make AJAX requests to retrieve data
&#x2022; JavaScript DOM manipulation to display it
&#x2022; <click> Cross-domain restrictions require the use of a proxy
&#x2022; OpenSocial containers include a request proxy
&#x2022; Allows gadgets to make AJAX requests to web services on other hosts
&#x2022; Proxy requires server-to-server authorization.
&#x2022; Can&#x2019;t use cookies, due to cross-domain restrictions
&#x2022; OAuth is the authorization solution built into OpenSocial
&#x2022; Open standard independent of OpenSocial
&#x2022; Used by Twitter, Photobucket, TripIt, many more
&#x2022; Allows secure communication between gadget request proxy and web services that gadgets call
&#x2022; Doesn&#x2019;t require container to have username and password
&#x2022; Instead, user is directed to the application that the gadget is trying to contact, and asked to authorize the gadget
&#x2022; Like using a Facebook app or Facebook Connect
&#x2022; If this all sounds kind of complicated, it is
&#x2022; The gadgets core API provides a function that makes it easy
&#x2022; <click> Gadgets make AJAX requests to retrieve data
&#x2022; JavaScript DOM manipulation to display it
&#x2022; <click> Cross-domain restrictions require the use of a proxy
&#x2022; OpenSocial containers include a request proxy
&#x2022; Allows gadgets to make AJAX requests to web services on other hosts
&#x2022; Proxy requires server-to-server authorization.
&#x2022; Can&#x2019;t use cookies, due to cross-domain restrictions
&#x2022; OAuth is the authorization solution built into OpenSocial
&#x2022; Open standard independent of OpenSocial
&#x2022; Used by Twitter, Photobucket, TripIt, many more
&#x2022; Allows secure communication between gadget request proxy and web services that gadgets call
&#x2022; Doesn&#x2019;t require container to have username and password
&#x2022; Instead, user is directed to the application that the gadget is trying to contact, and asked to authorize the gadget
&#x2022; Like using a Facebook app or Facebook Connect
&#x2022; If this all sounds kind of complicated, it is
&#x2022; The gadgets core API provides a function that makes it easy
&#x2022; The most important API in the entire gadgets specification
&#x2022; Almost every gadget will use it
&#x2022; Allows AJAX requests through the gadget request proxy
&#x2022; Provides option to use OAuth
&#x2022; Helpful options to automatically parse XML and JSON data
&#x2022; Calls a JavaScript function within your gadget to process results
&#x2022; Starts with a hard-coded URL
&#x2022; Search on JAC for most recent 20 unresolved issues, returns XML
&#x2022; Builds up parameter object to describe attributes of the request
&#x2022; In this case, only the type of content we&#x2019;re retrieving
&#x2022; DOM says that we expect an XML or HTML response
&#x2022; Automatically parsed into a DOM tree for us
&#x2022; This data is mostly public, so ignore authentication for now
&#x2022; Use makeRequest to call that URL
&#x2022; Pass the &#x201C;handleResponse&#x201D; function to it
&#x2022; When the request returns, invokes that function with the results
&#x2022; Object passed in contains parsed XML DOM in its &#x201C;data&#x201D; field
&#x2022; Pass it to the getTitle and getItems functions to extract out a list of issues
&#x2022; Pass the resulting objects to renderJiraIssues
&#x2022; I won&#x2019;t get into the details of those methods, not gadget-specific
&#x2022; Look at the source code online if you&#x2019;re curious
&#x2022; First dismisses the loading message we displayed earlier
&#x2022; Second adjusts height to exactly fit the list of issues we&#x2019;ve rendered
&#x2022; <click> This is what it looks like when it&#x2019;s done
&#x2022; Object passed in contains parsed XML DOM in its &#x201C;data&#x201D; field
&#x2022; Pass it to the getTitle and getItems functions to extract out a list of issues
&#x2022; Pass the resulting objects to renderJiraIssues
&#x2022; I won&#x2019;t get into the details of those methods, not gadget-specific
&#x2022; Look at the source code online if you&#x2019;re curious
&#x2022; First dismisses the loading message we displayed earlier
&#x2022; Second adjusts height to exactly fit the list of issues we&#x2019;ve rendered
&#x2022; <click> This is what it looks like when it&#x2019;s done
&#x2022; Doesn&#x2019;t address single-sign on. OAuth-based security model is unconventional
&#x2022; Built for situations where apps are written by small developers, targeting big social networks
&#x2022; Works for peer-to-peer type situations, but not optimal
&#x2022; In general, spec authors & Shindig implementors have low awareness of enterprise needs
&#x2022; This is getting better&#x2026;
&#x2022; Doesn&#x2019;t address single-sign on. OAuth-based security model is unconventional
&#x2022; Built for situations where apps are written by small developers, targeting big social networks
&#x2022; Works for peer-to-peer type situations, but not optimal
&#x2022; In general, spec authors & Shindig implementors have low awareness of enterprise needs
&#x2022; This is getting better&#x2026;
&#x2022; Doesn&#x2019;t address single-sign on. OAuth-based security model is unconventional
&#x2022; Built for situations where apps are written by small developers, targeting big social networks
&#x2022; Works for peer-to-peer type situations, but not optimal
&#x2022; In general, spec authors & Shindig implementors have low awareness of enterprise needs
&#x2022; This is getting better&#x2026;
&#x2022; A typical OpenSocial/Shindig deployment requires Shindig to run on a different domain than the containing app
&#x2022; Not realistic for install-it-yourself software
&#x2022; We had to compromise security model, rely on admins
&#x2022; Hard to write gadgets that work with multiple installations of a server
&#x2022;&#xA0;We implemented gadget pre-processing with a simple macro language to customize gadgets for each server URL
&#x2022; Many gadgets rely on resources on the web, particularly ganalytics
&#x2022; Unsuitable for secure or disconnected environments
&#x2022; A typical OpenSocial/Shindig deployment requires Shindig to run on a different domain than the containing app
&#x2022; Not realistic for install-it-yourself software
&#x2022; We had to compromise security model, rely on admins
&#x2022; Hard to write gadgets that work with multiple installations of a server
&#x2022;&#xA0;We implemented gadget pre-processing with a simple macro language to customize gadgets for each server URL
&#x2022; Many gadgets rely on resources on the web, particularly ganalytics
&#x2022; Unsuitable for secure or disconnected environments
&#x2022; A typical OpenSocial/Shindig deployment requires Shindig to run on a different domain than the containing app
&#x2022; Not realistic for install-it-yourself software
&#x2022; We had to compromise security model, rely on admins
&#x2022; Hard to write gadgets that work with multiple installations of a server
&#x2022;&#xA0;We implemented gadget pre-processing with a simple macro language to customize gadgets for each server URL
&#x2022; Many gadgets rely on resources on the web, particularly ganalytics
&#x2022; Unsuitable for secure or disconnected environments
&#x2022; OpenSocial 1.0 still in development, spec has been incomplete and sometimes unstable
&#x2022; Shindig in Apache incubator
&#x2022; Does not release often, has been very unstable
&#x2022; Cross-container compatibility issues are common
&#x2022; OpenSocial 1.0 still in development, spec has been incomplete and sometimes unstable
&#x2022; Shindig in Apache incubator
&#x2022; Does not release often, has been very unstable
&#x2022; Cross-container compatibility issues are common
&#x2022; OpenSocial 1.0 still in development, spec has been incomplete and sometimes unstable
&#x2022; Shindig in Apache incubator
&#x2022; Does not release often, has been very unstable
&#x2022; Cross-container compatibility issues are common
&#x2022; OpenSocial 1.0 spec effort is currently underway
&#x2022; No new features in 1.0
&#x2022; Defines a new extension process to allow innovation outside of the core
&#x2022; Anyone can join the spec list and take part
&#x2022; OpenSocial 1.0 spec effort is currently underway
&#x2022; No new features in 1.0
&#x2022; Defines a new extension process to allow innovation outside of the core
&#x2022; Anyone can join the spec list and take part
&#x2022; OpenSocial 1.0 spec effort is currently underway
&#x2022; No new features in 1.0
&#x2022; Defines a new extension process to allow innovation outside of the core
&#x2022; Anyone can join the spec list and take part
&#x2022; OpenSocial 1.0 spec effort is currently underway
&#x2022; No new features in 1.0
&#x2022; Defines a new extension process to allow innovation outside of the core
&#x2022; Anyone can join the spec list and take part
&#x2022; OpenSocial 1.0 spec effort is currently underway
&#x2022; No new features in 1.0
&#x2022; Defines a new extension process to allow innovation outside of the core
&#x2022; Anyone can join the spec list and take part
&#x2022; Experimental feature to allow gadgets to exchange messages with each other and with the container
&#x2022; Will allow for context-aware gadgets
&#x2022; Allows iframe-free gadgets
&#x2022; Used by YAP, experimentally available on iGoogle
&#x2022; We&#x2019;re very interested, but not ready for prime time
&#x2022; Allows iframe-free gadgets
&#x2022; Used by YAP, experimentally available on iGoogle
&#x2022; We&#x2019;re very interested, but not ready for prime time
&#x2022; Allows iframe-free gadgets
&#x2022; Used by YAP, experimentally available on iGoogle
&#x2022; We&#x2019;re very interested, but not ready for prime time