DJHell .'s Library tagged OpenSocial → View Popular

Filter:
All
Annotated

20 Jul 09

OpenSocial, OpenID, and OAuth: Oh, My! ‎(2008 Google I/O Session Videos and Slides)‎

A number of emerging technologies will soon collectively enable an open social web in which users control their information and it can flow between multiple sites and services. OpenID, OAuth, microformats, OpenSocial, the Social Graph API, friends-list portability, and more will be discussed, as well as a coherent vision for how the pieces fit together and how developers can start taking advantage of them now.

sites.google.com/...nsocial-openid-and-oauth-oh-my - Preview

OpenID OAuth OpenSocial Video presentation

13 Jun 09

GDD Japan 2009 - Designing OpenSocial Apps For Speed and Scale

www.slideshare.net/...ocial-apps-for-speed-and-scale - Preview

OpenSocial Präsentation Google Developer Day Optimierung Leistung

OpenSocial in the Cloud - OpenSocial

Some OpenSocial apps can be written entirely with client-side JavaScript and HTML, leveraging the container to serve the page and store application data. In this case, the app can scale effortlessly because the only request hitting your server is for the gadget specification which is typically cached by the container anyway.\n\nHowever, there are lots of reasons to consider using your own server:\n\n * Allows you to write code in the programing language of your choice.\n * Puts you in control of how much application data you can store.\n * Lets you combine data from users on multiple social networks.\n * Enables interaction with the OpenSocial REST API. \n\nSetting up an OpenSocial app that uses a third party server is fairly simple. There are a few gotchas and caveats, but the real issues come up when your app becomes successful - serving millions of users and sending thousands of requests per second. Apps can grow especially fast on social networks, so before you launch your next social app, you should think about how to scale up quickly if your app takes off.\n\nUnfortunately, scaling is a complex problem that's hard to solve quickly and expensive to implement. Luckily, there are several companies that provide cloud computing resources-places you can store data or run processes on virtual machines. These computing solutions manage huge infrastructures so you can focus on your applications and let the "cloud" handle all the requests and data at scale.\n\nThis tutorial focuses on a simple photo-sharing app that uses a third-party server to host photos and associated metadata. If this app is going to host millions of images and support many requests per second, we won't be able to run it on a single dedicated host. We'll break the app down and analyze the interactions between the OpenSocial App and the back end server. Then we'll implement the app in the cloud, first using Google App Engine, then leveraging Amazon's S3 data storage service. Finally, we'll look at several ways to reduce the amount of n

wiki.opensocial.org/index.php - Preview

OpenSocial Cloud Computing Open Source development articles

Apps can grow especially fast on social networks, so before you launch your next social app, you should think about how to scale up quickly if your app takes off.
Unfortunately, scaling is a complex problem that's hard to solve quickly and expensive to implement.
10 more annotations...
- If this app grows to serve millions of users and photos, shared hosting or even a dedicated server won't have the bandwidth or CPU cycles to handle all of the requests. We could invest in more servers and network infrastructure, shard the database, and load-balance requests, but that takes time, money, and expertise. If you'd rather work on the new features of the app, it's time to move into the cloud.
- It's important to focus on the interactions between the app and your server when designing an application that will run in the cloud. If we standardize the communication protocol and data format, we can easily change the server side implementation without modifying the OpenSocial app.
- You can configure the makeRequest method to digitally sign the requests your app makes to your server using OAuth's algorithm for parameter signing. This means that when your server receives a request, it can verify that the request came from your application hosted in a specific container. To implement this, the calls to makeRequest in the OpenSocial app spec XML specify that the request should be signed, and the code that handles requests on the server side verifies that a signature is included and valid
- When our server receives a request, we can verify that it came from our application by checking that the digital signature was signed by a valid container and that the application ID is correct.
- Since our server isn't storing any relationship data, the app will need to send us a list of user IDs so we can fetch the appropriate photos.
- Although it's outside the scope of this article, we could provide a mechanism for our OpenSocial app to request a one-time-use token that it would include in the request to upload a photo.
- Since the server doesn't store any relationship data, the PhotosHandler class checks the post data of the request for a list of IDs from the container.
- Note that the post data is URL-encoded in the request so the post method uses urllib.unquote before splitting the comma-separated list of person IDs.
- A common misconception when coding in the cloud is that storage space, CPU cycles, and bandwidth are unlimited. While the cloud hosting provider can, in theory, provide all the resources your app needs, hosting in the cloud ain't free so these resources are limited by your budget. Luckily, OpenSocial provides several mechanisms to cache images and data that will reduce the load on your server.
- In addition to reducing traffic to our server, this technique has the added benefit of being fast—requesting data from the Persistence API is much faster than making the round trip to your server.

27 May 09

OpenSocial API Blog: How OpenSocial v0.9 streamlines your app

One of the major updates to OpenSocial in the latest version is a new programming model that allows you to send social data directly from the container to your application's server, where you can use the data to render any content you want to show the user. This model lets you use your existing presentation layer (faster coding!) and reduces the number of requests needed to pass social data between clients, containers, and your app server (faster apps!). Here's a closer look...

blog.opensocial.org/...-v09-streamlines-your-app.html - Preview

OpenSocial OpenSocial 0.9 blog news new features data pipelining

14 May 09

OpenSocial API Blog: OpenSocial community defines version 0.9

A new version of the OpenSocial Specification hit the presses yesterday -- packed full of new features to make writing, testing, and maintaining apps much easier. From a streamlined JavaScript API, to a more efficient way to communicate between the app and your server, many of the OpenSocial v0.9 updates aim to make coding and rendering apps blazing fast

blog.opensocial.org/...munity-defines-version-09.html - Preview

OpenSocial OpenSocial 0.9 blog It news specification

22 Aug 08

OpenSocial API Blog: Let's get this Partuza started!

Do you wish you could develop and test your OpenSocial gadgets on your own local development machine or server? Or are you thinking of becoming an OpenSocial container but need an example of how you can get started?

If your answer to either of these qu

opensocialapis.blogspot.com/...-get-this-partuza-started.html - Preview

API blog Google OpenSocial Partuza PHP ungelesen importiert Open Source Source development