The document discusses OpenSocial, which aims to make the web more social by allowing developers to create social applications that can be installed and used within social networks through a common API. It describes how OpenSocial uses gadgets, which are applications defined by XML specs, to enable social apps to integrate with different social networks and platforms through standardized client-side and server-side APIs. The document provides examples of how gadgets work and how OpenSocial addresses the needs of both social networks and application developers.
Futuropolis 2058 Singapore - OpenSocial, a standard for the social webPatrick Chanezon
The latest developments in social networking platforms and their importance in connecting people, places and ideas will be presented. Interoperability of these various platforms is crucial to allow for the message of sustainability and the future of connectivity for citizens of the future.
Goodle Developer Days Madrid 2008 - Open Social UpdatePatrick Chanezon
Updates about the OpenSocial ecosystem at Google developer days Madrid including presentations from Netlog and Viadeo.
OpenSocial is an open specification defining a common API that works on many different social websites, including MySpace, Plaxo, Hi5, Ning, orkut, Friendster Salesforce.com and LinkedIn, among others. This allows developers to learn one API, then write a social application for any of those sites: Learn once, write anywhere.
In addition, in order to make it easier for developers of social sites to implement the API and make their site an OpenSocial container, the Apache project Shindig provides reference implementations for OpenSocial containers in two languages (Java, PHP). Shindig will define a language specific Service Provider Interface (SPI) that a social site can implement to connect Shindig to People, Persistence and Activities backend services for the social site. Shindig will then expose these services as OpenSocial JavaScript and REST APIs.
In this session we will explain what OpenSocial is, show examples of OpenSocial containers and applications, demonstrate how to create an OpenSocial application, and explain how to leverage Apache Shindig in order to implement an OpenSocial container.
Slides accompanying the paper:
Buckingham Shum, Simon (2008). Cohere: Towards Web 2.0 Argumentation. In: Proc. COMMA'08: 2nd International Conference on Computational Models of Argument, 28-30 May 2008, Toulouse, France. Preprint: http://oro.open.ac.uk/10421
This is a presentation on OpenSocial in the Enterprise given at Devfest 2009 in Buenos Aires Argentina on Nov 17, 2009 by Google Developer Advocate, Chris Schalk, eXo Platform CEO Benjamin Mestrallet, and Globant's Bruno Rovagnati
Are you a Sitecore developer with no experience with mobile development? Neither did Pieter while writing this synopsis. Join Pieter in his quest to become a mobile Go Go starting from a Mobile No No.
He will share his expectations and lessons learned of mobile development. Focussing on the why mobile development matters and the different technologies that are available. Ending with and introduction of the Sitecore mobile SDK and Xamarin.
Goodle Developer Days London 2008 - Open Social UpdatePatrick Chanezon
Updates about the OpenSocial ecosystem at Google developer days London including presentations from Netlog and Viadeo.
OpenSocial is an open specification defining a common API that works on many different social websites, including MySpace, Plaxo, Hi5, Ning, orkut, Friendster Salesforce.com and LinkedIn, among others. This allows developers to learn one API, then write a social application for any of those sites: Learn once, write anywhere.
In addition, in order to make it easier for developers of social sites to implement the API and make their site an OpenSocial container, the Apache project Shindig provides reference implementations for OpenSocial containers in two languages (Java, PHP). Shindig will define a language specific Service Provider Interface (SPI) that a social site can implement to connect Shindig to People, Persistence and Activities backend services for the social site. Shindig will then expose these services as OpenSocial JavaScript and REST APIs.
In this session we will explain what OpenSocial is, show examples of OpenSocial containers and applications, demonstrate how to create an OpenSocial application, and explain how to leverage Apache Shindig in order to implement an OpenSocial container.
Goodle Developer Days Munich 2008 - Open Social UpdatePatrick Chanezon
Updates about the OpenSocial ecosystem at Google developer days Munich, including presentations from Xing, Lokalisten, netlog and Viadeo..
OpenSocial is an open specification defining a common API that works on many different social websites, including MySpace, Plaxo, Hi5, Ning, orkut, Friendster Salesforce.com and LinkedIn, among others. This allows developers to learn one API, then write a social application for any of those sites: Learn once, write anywhere.
In addition, in order to make it easier for developers of social sites to implement the API and make their site an OpenSocial container, the Apache project Shindig provides reference implementations for OpenSocial containers in two languages (Java, PHP). Shindig will define a language specific Service Provider Interface (SPI) that a social site can implement to connect Shindig to People, Persistence and Activities backend services for the social site. Shindig will then expose these services as OpenSocial JavaScript and REST APIs.
In this session we will explain what OpenSocial is, show examples of OpenSocial containers and applications, demonstrate how to create an OpenSocial application, and explain how to leverage Apache Shindig in order to implement an OpenSocial container.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
Futuropolis 2058 Singapore - OpenSocial, a standard for the social webPatrick Chanezon
The latest developments in social networking platforms and their importance in connecting people, places and ideas will be presented. Interoperability of these various platforms is crucial to allow for the message of sustainability and the future of connectivity for citizens of the future.
Goodle Developer Days Madrid 2008 - Open Social UpdatePatrick Chanezon
Updates about the OpenSocial ecosystem at Google developer days Madrid including presentations from Netlog and Viadeo.
OpenSocial is an open specification defining a common API that works on many different social websites, including MySpace, Plaxo, Hi5, Ning, orkut, Friendster Salesforce.com and LinkedIn, among others. This allows developers to learn one API, then write a social application for any of those sites: Learn once, write anywhere.
In addition, in order to make it easier for developers of social sites to implement the API and make their site an OpenSocial container, the Apache project Shindig provides reference implementations for OpenSocial containers in two languages (Java, PHP). Shindig will define a language specific Service Provider Interface (SPI) that a social site can implement to connect Shindig to People, Persistence and Activities backend services for the social site. Shindig will then expose these services as OpenSocial JavaScript and REST APIs.
In this session we will explain what OpenSocial is, show examples of OpenSocial containers and applications, demonstrate how to create an OpenSocial application, and explain how to leverage Apache Shindig in order to implement an OpenSocial container.
Slides accompanying the paper:
Buckingham Shum, Simon (2008). Cohere: Towards Web 2.0 Argumentation. In: Proc. COMMA'08: 2nd International Conference on Computational Models of Argument, 28-30 May 2008, Toulouse, France. Preprint: http://oro.open.ac.uk/10421
This is a presentation on OpenSocial in the Enterprise given at Devfest 2009 in Buenos Aires Argentina on Nov 17, 2009 by Google Developer Advocate, Chris Schalk, eXo Platform CEO Benjamin Mestrallet, and Globant's Bruno Rovagnati
Are you a Sitecore developer with no experience with mobile development? Neither did Pieter while writing this synopsis. Join Pieter in his quest to become a mobile Go Go starting from a Mobile No No.
He will share his expectations and lessons learned of mobile development. Focussing on the why mobile development matters and the different technologies that are available. Ending with and introduction of the Sitecore mobile SDK and Xamarin.
Goodle Developer Days London 2008 - Open Social UpdatePatrick Chanezon
Updates about the OpenSocial ecosystem at Google developer days London including presentations from Netlog and Viadeo.
OpenSocial is an open specification defining a common API that works on many different social websites, including MySpace, Plaxo, Hi5, Ning, orkut, Friendster Salesforce.com and LinkedIn, among others. This allows developers to learn one API, then write a social application for any of those sites: Learn once, write anywhere.
In addition, in order to make it easier for developers of social sites to implement the API and make their site an OpenSocial container, the Apache project Shindig provides reference implementations for OpenSocial containers in two languages (Java, PHP). Shindig will define a language specific Service Provider Interface (SPI) that a social site can implement to connect Shindig to People, Persistence and Activities backend services for the social site. Shindig will then expose these services as OpenSocial JavaScript and REST APIs.
In this session we will explain what OpenSocial is, show examples of OpenSocial containers and applications, demonstrate how to create an OpenSocial application, and explain how to leverage Apache Shindig in order to implement an OpenSocial container.
Goodle Developer Days Munich 2008 - Open Social UpdatePatrick Chanezon
Updates about the OpenSocial ecosystem at Google developer days Munich, including presentations from Xing, Lokalisten, netlog and Viadeo..
OpenSocial is an open specification defining a common API that works on many different social websites, including MySpace, Plaxo, Hi5, Ning, orkut, Friendster Salesforce.com and LinkedIn, among others. This allows developers to learn one API, then write a social application for any of those sites: Learn once, write anywhere.
In addition, in order to make it easier for developers of social sites to implement the API and make their site an OpenSocial container, the Apache project Shindig provides reference implementations for OpenSocial containers in two languages (Java, PHP). Shindig will define a language specific Service Provider Interface (SPI) that a social site can implement to connect Shindig to People, Persistence and Activities backend services for the social site. Shindig will then expose these services as OpenSocial JavaScript and REST APIs.
In this session we will explain what OpenSocial is, show examples of OpenSocial containers and applications, demonstrate how to create an OpenSocial application, and explain how to leverage Apache Shindig in order to implement an OpenSocial container.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
17. The social internet
A social website..
• Provides a feature that becomes more engaging as the number of users
grows.
• Uses relationships between people to present users interesting
information.
17
19. The social internet
A social website..
• Has overhead to manage users and relationships.
• Grows slowly because users must sign up to use the site.
What if we remove
the overhead?
• Developers can focus
on providing
features, not
managing users.
19
20. The social internet
A social network..
• Manages large numbers of users and relationships.
• Is slow to add new features.
20
22. The social internet
How do we add new features to social networks?
• Make the social network a platform.
• Give creative developers the tools to add the features themselves.
22
23. The social internet
A social application...
• Lets the social network manage users and relationships.
• Adds new features to the social network.
• Lets users “install” the application without signing up for new accounts.
• Grows quickly because users are already communicating with each
other.
23
35. Gadgets
A gadget spec:
• Is an XML file.
• Defines metadata about an OpenSocial app.
• Is highly cacheable and does not need a high performance server.
Gadgets use existing web standards
• XML to define metadata.
• HTML for markup.
• JavaScript for interactivity.
• CSS for presentation.
35
36. Gadgets
A gadget server:
• Takes the gadget spec as input.
• Performs optimizations on the gadget spec.
• Outputs HTML, JavaScript, and CSS as one document.
36
37. Gadgets
A container:
• Displays the social network’s user interface.
• Opens an IFrame to the rendered gadget.
Containers and gadget
servers are both run by
the social network, but
do not need to be on
the same machine, or
even domain.
37
38. Gadgets
Example gadget XML spec:
• Uses HTML to print “Hello World”.
• Colors the text red with CSS.
• Dynamically adjusts the height of the gadget with JavaScript.
<?xml version=quot;1.0quot; encoding=quot;UTF-8quot; ?>
<Module>
<ModulePrefs title=quot;Hello World!quot;>
<Require feature=quot;dynamic-heightquot; />
</ModulePrefs>
<Content type=quot;htmlquot;>
<![CDATA[
<h1>Hello World</h1>
<style type=quot;text/cssquot;>
h1 { color: #dd0000; }
</style>
<script type=quot;text/javascriptquot;>
gadgets.window.adjustHeight();
</script>
]]>
</Content>
</Module>
38
40. Gadgets
Requesting the gadget XML spec:
1. The client requests an app to be rendered.
2. The container fetches the gadget XML spec from its host.
40
41. Gadgets
Requesting the gadget XML spec:
1. The client requests an app to be rendered.
2. The container fetches the gadget XML spec from its host.
3. The container renders the gadget into HTML, which is displayed
to the client.
41
42. Gadgets
Requesting the gadget XML spec:
• Because the gadget spec is simple, it can be cached easily.
• Caching reduces the load on your server, great when you have millions
of users.
42
43. Gadgets
Requesting a cached gadget XML spec:
1.The client requests an app to be rendered. The container already
has a copy of the spec stored in its cache.
43
44. Gadgets
Requesting a cached gadget XML spec:
1.The client requests an app to be rendered. The container already
has a copy of the spec stored in its cache.
2.The container renders the gadget into HTML, which is displayed
to the client.
44
45. Gadgets
What kind of rewriting is done by the gadget server?
• Rewrite links to use content proxies.
• Rewrite relative links to full paths (some containers).
• Return only content for the current view.
45
46. Gadgets
What are views?
• Gadgets can render in different locations on a container.
• Rendering area changes from small to large.
• Certain pages might be public, some are private.
• Containers may have different policies depending on the page,
especially when the gadget displays ads.
• Views provide a way for gadgets to provide different functionality
depending on where it is rendered.
46
49. Gadgets
Working with views in the gadget XML:
• <Content> sections are repeated for each view.
• Add a view=quot;view namequot; attribute to each section.
• Content sections may support multiple views, for example
view=quot;home,canvasquot;
<?xml version=quot;1.0quot; encoding=quot;UTF-8quot; ?>
<Module>
<ModulePrefs title=quot;Hello World!quot;>
<Require feature=quot;dynamic-heightquot; />
</ModulePrefs>
<Content type=quot;htmlquot; view=quot;homequot;>
<![CDATA[
...
]]>
</Content>
<Content type=quot;htmlquot; view=quot;canvasquot;>
<![CDATA[
...
]]>
</Content>
</Module>
49
50. Gadgets
JavaScript utility functions for gadgets:
• gadgets.io.makeRequest()
Make cross-domain AJAX calls to remote servers.
• gadgets.json.parse() and gadgets.json.stringify()
Native JSON support.
• gadgets.util.escapeString()
Make text safe for display via innerHTML.
• gadgets.util.registerOnLoadHandler()
Execute code when the page is finished loading.
50
51. Gadgets
gadgets.io.makeRequest():
• Make cross-domain AJAX calls to remote servers.
Remote content:
• Most interesting gadgets will need to
work with content stored on different
servers.
• AJAX cannot cross domains, so you
cannot request content from your own
server.
• JSONP is only really good for one-way
data transfer.
• Gadgets with millions of users can
overwhelm a remote site.
51
52. Gadgets
Requesting remote content:
1.The rendered app calls gadgets.io.makeRequest() to fetch
remote content. This call is sent to the container.
52
53. Gadgets
Requesting remote content:
1.The rendered app calls gadgets.io.makeRequest() to fetch
remote content. This call is sent to the container.
2.The container requests content from the specified URL.
53
54. Gadgets
Requesting remote content:
1.The rendered app calls gadgets.io.makeRequest() to fetch
remote content. This call is sent to the container.
2.The container requests content from the specified URL.
3.The container returns the response to the application, which renders
the data.
54
55. Gadgets
Add extra features to your gadget:
• dynamic-height - Change the size of your gadget in the container.
• views - Navigate between different surfaces of the container.
• skins - Make your gadget change its styles to match the container.
• Containers may offer custom features...
<?xml version=quot;1.0quot; encoding=quot;UTF-8quot; ?>
<Module>
<ModulePrefs title=quot;Hello World!quot;>
<Require feature=quot;dynamic-heightquot; />
</ModulePrefs>
<Content type=quot;htmlquot;>
<![CDATA[
...
]]>
</Content>
</Module>
55
56. Gadgets
<?xml version=quot;1.0quot; encoding=quot;UTF-8quot; ?>
<Module>
<ModulePrefs title=quot;Hello Social!quot;>
<Require feature=quot;opensocial-0.8quot; />
</ModulePrefs>
<Content type=quot;htmlquot;>
<![CDATA[
...
]]>
</Content>
</Module>
The OpenSocial JavaScript API is a gadget feature, too!
56
58. The OpenSocial JavaScript API
Representing users:
• Client-side, users must work with the VIEWER and the OWNER.
58
59. The OpenSocial JavaScript API
Multiple personalities:
• When you visit your own profile, you are both the VIEWER and the
OWNER.
59
60. The OpenSocial JavaScript API
OpenSocial requests:
• An OpenSocial DataRequest is created.
• Requests are added to the DataRequest.
• The DataRequest is sent to the server asynchronously.
• When the request finishes, the supplied callback will be called.
function request() {
var req = opensocial.newDataRequest();
req.add(req.newFetchPersonRequest(quot;OWNERquot;), quot;get_ownerquot;);
req.add(req.newFetchPersonRequest(quot;VIEWERquot;), quot;get_viewerquot;);
req.add(req.newFetchActivitiesRequest(quot;VIEWERquot;), quot;vactivitiesquot;);
req.add(req.newFetchPersonAppDataRequest(quot;OWNERquot;, quot;*quot;), quot;odataquot;);
...
req.send(response);
};
function response(data) { ... };
gadgets.util.registerOnLoadHandler(request);
60
61. The OpenSocial JavaScript API
OpenSocial responses:
• Responses are bundled according to the keys specified in the request.
• Check for an error at the global response level.
• Check for an error at the specific response level.
• Use getData() to retrieve the actual information in a request.
function response(data) {
if (data.hadError()) {
if (data.get(quot;get_ownerquot;).hadError()) {
...
}
if (data.get(quot;get_viewerquot;).hadError()) {
...
}
...
}
var owner = data.get(quot;get_ownerquot;).getData();
var viewer = data.get(quot;get_viewerquot;).getData();
};
61
62. The OpenSocial JavaScript API
Working with people:
• opensocial.Person - JavaScript representation of a user.
62
63. The OpenSocial JavaScript API
Request one person:
req.add(req.newFetchPersonRequest(idspec, opt_params), quot;keyquot;);
• idspec can be either “VIEWER”, “OWNER” or an ID number.
• opt_params contains extra request parameters, such as which profile
fields to fetch.
newFetchPersonRequest responses:
var owner = data.get(quot;keyquot;).getData();
alert(owner.getDisplayName());
• Data contains a single opensocial.Person
object.
• Person objects can contain lots of information,
such as addresses, companies, phone numbers,
favorite movies, and thumbnail urls.
63
64. The OpenSocial JavaScript API
Methods available on an OpenSocial Person:
• getDisplayName()
Gets a text display name for this person; guaranteed to return a useful
string.
• getField(key, opt_params)
Gets data for this person that is associated with the specified key.
• getId()
Gets an ID that can be permanently associated with this person.
• isOwner()
Returns true if this person object represents the owner
of the current page.
• isViewer()
Returns true if this person object represents the
currently logged in user.
64
66. The OpenSocial JavaScript API
Working with people:
• A Collection represents many opensocial.Person objects.
66
67. The OpenSocial JavaScript API
Request many people:
var idspec = opensocial.newIdSpec({
“userId” : “OWNER”,
“groupId” : “FRIENDS”
});
req.add(req.newFetchPeopleRequest(idspec, opt_params), quot;keyquot;);
• idspec is an object that can represent groups of people. “userId” can be
“VIEWER” or “OWNER” or an ID, and “groupId” can be “SELF”,
“FRIENDS”, or the name of a group.
• opt_params contains extra request parameters, such as which profile
fields to fetch, and how to order or filter the returned people.
newFetchPersonRequest responses:
var owner_friends = data.get(quot;keyquot;).getData();
owner_friends.each(function (person) {
alert(person.getDisplayName());
});
• Data contains a Collection of opensocial.Person
objects. Iterate over these by using the each() method.
67
68. The OpenSocial JavaScript API
Working with data:
• Persistent data gives apps key, value storage directly on the container.
• String only, but conversion to JSON allows for storage of complex
objects.
• Storage per app per user - scales well with growth.
• Ideal for settings, customizations.
68
69. The OpenSocial JavaScript API
Set persistent data:
req.add(req.newUpdatePersonAppDataRequest(idspec, key, value));
• idspec can only be “VIEWER”.
• key is the name under which this data will be stored.
• value is a string representing the data to store.
69
70. The OpenSocial JavaScript API
Fetch persistent data:
var idspec = opensocial.newIdSpec({
quot;userIdquot; : quot;OWNERquot;,
quot;groupIdquot; : quot;SELFquot;
});
req.add(req.newFetchPersonAppDataRequest(idspec, keys),
quot;keyquot;);
req.add(req.newFetchPersonRequest(quot;OWNERquot;), quot;ownerkeyquot;);
• idspec is an object that can represent groups of people, the same as
newFetchPeopleRequest.
• keys is a list of persistent data keys to retrieve the data for.
• The owner is requested because the data returned is indexed by user ID
and we want the owner’s data.
newFetchPersonAppDataRequest responses:
var app_data = data.get(quot;keyquot;).getData();
var value = app_data[owner.getId()][key];
70
71. The OpenSocial JavaScript API
Fetch persistent data:
• Data is returned as an object indexed by ID number, then as an object
indexed by key name, even if there is only data returned for one user!
{ quot;1234567890quot; : { quot;key1quot; : quot;value1quot; } }
• One person, multiple keys:
{
quot;1234567890quot; : {
quot;key1quot; : quot;value1quot;,
quot;key2quot; : quot;value2quot;
}
}
• Multiple people:
{
quot;1234567890quot; : { quot;key1quot; : quot;value1quot; },
quot;2345678901quot; : { quot;key1quot; : quot;value2quot; }
}
71
72. The OpenSocial JavaScript API
Working with activities:
• API to post information about what users are doing with your app.
• Many containers have support for images and some HTML.
• Channel to grow your application.
orkut MySpace hi5
72
73. The OpenSocial JavaScript API
Post an activity:
function postActivity(text) {
var params = {};
params[opensocial.Activity.Field.TITLE] = text;
var activity = opensocial.newActivity(params);
opensocial.requestCreateActivity(activity,
opensocial.CreateActivityPriority.HIGH, callback);
};
• Assign the activity text to the TITLE field.
• Call opensocial.newActivity() to create a new Activity instance.
• Call opensocial.requestCreateActivity() to post the activity to the
container.
73
75. RESTful and RPC protocols
Opens new development models
• Background processing.
• Easier Flash integration.
• Mobile applications.
75
76. RESTful and RPC protocols
Communication methods:
• RESTful (Representational State Transfer)
• RPC (Remote Procedure Call)
Formats:
• XML
• JSON
• AtomPub
76
77. RESTful and RPC protocols
REST:
• Resources are URLs.
Example - People:
• All people connected to the given user:
/people/{guid}/@all
• All friends of the given user:
/people/{guid}/@friends
• Profile of the given user:
/people/{guid}/@self
• Profile of the authenticated user:
/people/@me/@self
• Supported Person fields:
/people/@supportedFields
77
81. RESTful and RPC protocols
REST:
• Perform operations using different HTTP methods on each URL.
CRUD: HTTP:
• Create • POST
• Retrieve • GET
• Update • PUT
• Delete • DELETE
81
82. RESTful and RPC protocols
REST has some disadvantages:
• Batch support requires multiple HTTP requests, or a contrived URL
scheme.
• Specifying multiple users via querystring is difficult. Is
?uid=1234,5678 the same resource as ?uid=5678,1234 ?
82
84. RESTful and RPC protocols
Authentication:
• Both protocols use OAuth to identify users and apps.
• Depending on what the application needs to do, it can use two-legged
or three-legged OAuth.
Two-legged OAuth:
• The application authenticates directly with the container.
• Perform non-user specific operations:
• Update persistent data for app users.
• Can request information for users who have shared their profile
information with the app.
Three-legged OAuth:
• The user tells the container to give profile access to the application.
• Perform user specific operations:
• Post activities.
• Fetch friends of the current user.
84
85. RESTful and RPC protocols
Client libraries are being created for PHP, Java, and Python.
• Help you connect to OpenSocial containers, and work with social
data on your server.
Sample: log into a container:
85
86. RESTful and RPC protocols
RESTful and RPC use OAuth for authentication
• OAuth is an open standard.
• Client libraries will help make this process easier for developers.
Sample: use OAuth to get an access token for a user:
86
87. RESTful and RPC protocols
• Once OAuth is used, you can store a user token for later access.
Sample: use an existing token:
87
88. RESTful and RPC protocols
• Once authentication has happened, requests are easy:
Sample: Fetch the current user:
88
89. RESTful and RPC protocols
Sample: Fetch the current user’s friends:
89
91. Shindig
Writing a gadget server is difficult:
• Fast changing API - hard to keep up.
• Standardization is hard to get right.
• Costs ¥ / !
91
92. Shindig
Apache Shindig to the rescue!
• Open Source project.
• Available in Java and PHP.
• Run by itself and connect to an
existing social site to add
OpenSocial support.
• Goal: Launch a
new (simple)
container in under
an hour’s worth
of work
http://incubator.apache.org/shindig/
92
95. Caja
When JavaScript goes bad
• Gadgets can be a new vector for phishing, spam, malware.
• Social spread of gadgets can spread bad gadgets too.
• Caja reduces threats with a JavaScript
sanitizer as an additional quot;sandboxquot;
on top of iFrame protection.
95
96. Caja
Caja is:
• A capability-based Javascript sanitizer.
• An Open Source project from Google.
• Optional but recommended for
OpenSocial containers.
• Will eventually be secure enough
to run gadgets
inline instead of in iframes.
http://code.google.com/p/google-caja/
96
97. Templates
Need for a templating language:
• Developers need a simple way to convert OpenSocial data to HTML.
• DOM manipulation is slow and ugly.
• innerHTML is unsafe.
97
107. Challenges
Cross container development is still tricky:
• Containers may not follow the standard.
• Containers may follow the standard but have different policies.
• Follow best practices:
http://tinyurl.com/4nuzll
107
108. Challenges
No central directory
• Hard for apps to spread to many containers.
• Apps need to work with different install processes.
• Directory approval requirements vary from container to container.
108