Open Social In The Enterprise

1,390 views
1,314 views

Published on

Published in: Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,390
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
31
Comments
0
Likes
3
Embeds 0
No embeds

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
  • Open Social In The Enterprise

    1. 1. OpenSocial in the Enterprise Tim Moore Atlassian Developer
    2. 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. 3. Our Problem
    4. 4. Today Enterprise apps are silos
    5. 5. Source Code Today Enterprise apps are silos
    6. 6. Source Code Issues & Tasks Today Enterprise apps are silos
    7. 7. Source Code Issues & Tasks Wiki Today Enterprise apps are silos
    8. 8. Too Many Dashboards
    9. 9. Too Many Dashboards
    10. 10. Integration with Non-Atlassian apps
    11. 11. N:M Versions Problem
    12. 12. Solution: OpenSocial Gadgets
    13. 13. What is OpenSocial?
    14. 14. Social Data Model
    15. 15. Web Service APIs
    16. 16. Gadgets
    17. 17. Gadget Benefits
    18. 18. Gadget Benefits • Easy!
    19. 19. Gadget Benefits • Easy! • Safe
    20. 20. Gadget Benefits • Easy! • Safe • Write Once, Display Everywhere
    21. 21. Gadgets are a Great Solution for Dashboards
    22. 22. Open standard for enterprise OpenSocial application connection
    23. 23. view complete project single activity stream comment & interact Open standard for enterprise OpenSocial application connection
    24. 24. Not just about portals, Managers Do Email or internal applications.
    25. 25. view activity & status create issues Not just about portals, Managers Do Email or internal applications.
    26. 26. Open Standards, Industry Support
    27. 27. Apache Shindig
    28. 28. Anatomy of a Gadget
    29. 29. Anatomy of a Gadget • XML Spec File • Metadata, HTML Content, and JavaScript
    30. 30. Anatomy of a Gadget • XML Spec File • Metadata, HTML Content, and JavaScript • Core JavaScript API • Access Preferences, Make Requests
    31. 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. 32. Architecture
    33. 33. XML Spec File
    34. 34. <ModulePrefs>
    35. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 45. Requesting Data from Web Services
    46. 46. Requesting Data from Web Services • AJAX + DOM
    47. 47. Requesting Data from Web Services • AJAX + DOM • Request Proxy
    48. 48. Requesting Data from Web Services • AJAX + DOM • Request Proxy • OAuth
    49. 49. gadgets io . .makeRequest ) (
    50. 50. What Can You Call?
    51. 51. What Can You Call? • Any URL
    52. 52. What Can You Call? • Any URL • XML and JSON are the most useful
    53. 53. What Can You Call? • Any URL • XML and JSON are the most useful • REST-style APIs are the most convenient
    54. 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. 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. 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. 57. Challenges
    58. 58. Enterprise Readiness
    59. 59. Enterprise Readiness • SSO/Security
    60. 60. Enterprise Readiness • SSO/Security • Assumes big container, little app servers
    61. 61. Enterprise Readiness • SSO/Security • Assumes big container, little app servers • Low awareness of enterprise needs
    62. 62. Running Behind the Firewall
    63. 63. Running Behind the Firewall • Deployment issues
    64. 64. Running Behind the Firewall • Deployment issues • Portable gadgets
    65. 65. Running Behind the Firewall • Deployment issues • Portable gadgets • Google Analytics in gadgets
    66. 66. Immaturity
    67. 67. Immaturity • No 1.0 spec yet
    68. 68. Immaturity • No 1.0 spec yet • Shindig still incubating
    69. 69. Immaturity • No 1.0 spec yet • Shindig still incubating • Compatibility: more theory than reality
    70. 70. Whatʼs Next?
    71. 71. OpenSocial 1.0
    72. 72. OpenSocial 1.0 • In progress now
    73. 73. OpenSocial 1.0 • In progress now • Focus on clean up & clarification
    74. 74. OpenSocial 1.0 • In progress now • Focus on clean up & clarification • Compliance tests
    75. 75. OpenSocial 1.0 • In progress now • Focus on clean up & clarification • Compliance tests • Extension process
    76. 76. OpenSocial 1.0 • In progress now • Focus on clean up & clarification • Compliance tests • Extension process • You can join in
    77. 77. PubSub
    78. 78. Caja
    79. 79. Caja • Safer JavaScript & CSS
    80. 80. Caja • Safer JavaScript & CSS • Helps prevent phishing, script injection, history sniffing, etc.
    81. 81. Caja • Safer JavaScript & CSS • Helps prevent phishing, script injection, history sniffing, etc. • In production, but still tricky to use
    82. 82. Questions?

    ×