Your SlideShare is downloading. ×
Open Social In The Enterprise
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Open Social In The Enterprise

1,211
views

Published on

Published in: Technology, Business

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,211
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
30
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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

    • 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
    • 3. Our Problem
    • 4. Today Enterprise apps are silos
    • 5. Source Code Today Enterprise apps are silos
    • 6. Source Code Issues & Tasks Today Enterprise apps are silos
    • 7. Source Code Issues & Tasks Wiki Today Enterprise apps are silos
    • 8. Too Many Dashboards
    • 9. Too Many Dashboards
    • 10. Integration with Non-Atlassian apps
    • 11. N:M Versions Problem
    • 12. Solution: OpenSocial Gadgets
    • 13. What is OpenSocial?
    • 14. Social Data Model
    • 15. Web Service APIs
    • 16. Gadgets
    • 17. Gadget Benefits
    • 18. Gadget Benefits • Easy!
    • 19. Gadget Benefits • Easy! • Safe
    • 20. Gadget Benefits • Easy! • Safe • Write Once, Display Everywhere
    • 21. Gadgets are a Great Solution for Dashboards
    • 22. Open standard for enterprise OpenSocial application connection
    • 23. view complete project single activity stream comment & interact Open standard for enterprise OpenSocial application connection
    • 24. Not just about portals, Managers Do Email or internal applications.
    • 25. view activity & status create issues Not just about portals, Managers Do Email or internal applications.
    • 26. Open Standards, Industry Support
    • 27. Apache Shindig
    • 28. Anatomy of a Gadget
    • 29. Anatomy of a Gadget • XML Spec File • Metadata, HTML Content, and JavaScript
    • 30. Anatomy of a Gadget • XML Spec File • Metadata, HTML Content, and JavaScript • Core JavaScript API • Access Preferences, Make Requests
    • 31. 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
    • 32. Architecture
    • 33. XML Spec File
    • 34. <ModulePrefs>
    • 35. <ModulePrefs> <?xml version="1.0" encoding="UTF-8" ?> <Module> <ModulePrefs title="JIRA Issues" author="Atlassian" thumbnail="http://labs.atlassian.com/svn/GADGETS/ trunk/jira-issues/basic/jira-issues-thumbnail.png" description="A list of recently created Issues"> <Require feature="minimessage" /> <Require feature="dynamic-height" /> </ModulePrefs>
    • 36. <ModulePrefs> <?xml version="1.0" encoding="UTF-8" ?> <Module> <ModulePrefs title="JIRA Issues" author="Atlassian" thumbnail="http://labs.atlassian.com/svn/GADGETS/ trunk/jira-issues/basic/jira-issues-thumbnail.png" description="A list of recently created Issues"> <Require feature="minimessage" /> <Require feature="dynamic-height" /> </ModulePrefs>
    • 37. <ModulePrefs> <?xml version="1.0" encoding="UTF-8" ?> <Module> <ModulePrefs title="JIRA Issues" author="Atlassian" thumbnail="http://labs.atlassian.com/svn/GADGETS/ trunk/jira-issues/basic/jira-issues-thumbnail.png" description="A list of recently created Issues"> <Require feature="minimessage" /> <Require feature="dynamic-height" /> </ModulePrefs>
    • 38. <UserPref> <UserPref name="show_date" display_name="Show Dates?" datatype="bool" default_value="true"/> <UserPref name="show_summ" display_name="Show Summaries?" datatype="bool" default_value="true"/> <UserPref name="num_entries" display_name="Number of Entries:" default_value="5" required="true"/>
    • 39. <UserPref> <UserPref name="show_date" display_name="Show Dates?" datatype="bool" default_value="true"/> <UserPref name="show_summ" display_name="Show Summaries?" datatype="bool" default_value="true"/> <UserPref name="num_entries" display_name="Number of Entries:" default_value="5" required="true"/>
    • 40. <UserPref> <UserPref name="show_date" display_name="Show Dates?" datatype="bool" default_value="true"/> <UserPref name="show_summ" display_name="Show Summaries?" datatype="bool" default_value="true"/> <UserPref name="num_entries" display_name="Number of Entries:" default_value="5" required="true"/>
    • 41. <Content> <Content type="html"><![CDATA[ <link rel="stylesheet" href="http://labs.atlassian.com/svn/GADGETS/trunk/ jira-issues/basic/jira-issues.css"> <div id="content_div"></div> <script type="text/javascript" src="http://labs.atlassian.com/svn/GADGETS/trunk/ jira-issues/basic/jira-issues.js"></script> ]]></Content> </Module>
    • 42. 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);
    • 43. 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);
    • 44. 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);
    • 45. Requesting Data from Web Services
    • 46. Requesting Data from Web Services • AJAX + DOM
    • 47. Requesting Data from Web Services • AJAX + DOM • Request Proxy
    • 48. Requesting Data from Web Services • AJAX + DOM • Request Proxy • OAuth
    • 49. gadgets io . .makeRequest ) (
    • 50. What Can You Call?
    • 51. What Can You Call? • Any URL
    • 52. What Can You Call? • Any URL • XML and JSON are the most useful
    • 53. What Can You Call? • Any URL • XML and JSON are the most useful • REST-style APIs are the most convenient
    • 54. Fetching Issues function fetchIssues() { var url = "http://jira.atlassian.com/sr/" + "jira.issueviews:searchrequest-xml" + "/temp/SearchRequest.xml?" + "created%3Aprevious=-1w&resolution=-1" + "&sorter/field=issuekey&sorter/order=DESC" + "&sorter/field=created&sorter/order=DESC" + "&tempMax=20"; var params = {}; params[gadgets.io.RequestParameters.CONTENT_TYPE] = gadgets.io.ContentType.DOM; gadgets.io.makeRequest(url, handleResponse, params); }
    • 55. Handling the Response function handleResponse(obj) { var domData = obj.data; var jiraIssues = { title : getTitle(domData), items : getItems(domData) }; renderJiraIssues(jiraIssues); msg.dismissMessage(loadMessage); gadgets.window.adjustHeight(); }
    • 56. Handling the Response function handleResponse(obj) { var domData = obj.data; var jiraIssues = { title : getTitle(domData), items : getItems(domData) }; renderJiraIssues(jiraIssues); msg.dismissMessage(loadMessage); gadgets.window.adjustHeight(); }
    • 57. Challenges
    • 58. Enterprise Readiness
    • 59. Enterprise Readiness • SSO/Security
    • 60. Enterprise Readiness • SSO/Security • Assumes big container, little app servers
    • 61. Enterprise Readiness • SSO/Security • Assumes big container, little app servers • Low awareness of enterprise needs
    • 62. Running Behind the Firewall
    • 63. Running Behind the Firewall • Deployment issues
    • 64. Running Behind the Firewall • Deployment issues • Portable gadgets
    • 65. Running Behind the Firewall • Deployment issues • Portable gadgets • Google Analytics in gadgets
    • 66. Immaturity
    • 67. Immaturity • No 1.0 spec yet
    • 68. Immaturity • No 1.0 spec yet • Shindig still incubating
    • 69. Immaturity • No 1.0 spec yet • Shindig still incubating • Compatibility: more theory than reality
    • 70. Whatʼs Next?
    • 71. OpenSocial 1.0
    • 72. OpenSocial 1.0 • In progress now
    • 73. OpenSocial 1.0 • In progress now • Focus on clean up & clarification
    • 74. OpenSocial 1.0 • In progress now • Focus on clean up & clarification • Compliance tests
    • 75. OpenSocial 1.0 • In progress now • Focus on clean up & clarification • Compliance tests • Extension process
    • 76. OpenSocial 1.0 • In progress now • Focus on clean up & clarification • Compliance tests • Extension process • You can join in
    • 77. PubSub
    • 78. Caja
    • 79. Caja • Safer JavaScript & CSS
    • 80. Caja • Safer JavaScript & CSS • Helps prevent phishing, script injection, history sniffing, etc.
    • 81. Caja • Safer JavaScript & CSS • Helps prevent phishing, script injection, history sniffing, etc. • In production, but still tricky to use
    • 82. Questions?