- Programming Social Applications
- Dedication
- Preface
- 1. Social Application Container Core Concepts
- What Is a Social Application Container?
- Implementing Proprietary Versus Open Standards
- The Embedded Application: Building in a Black Box
- Embedded Application Security
- The External Application: Integrating Social Data Outside the Container
- Application Views
- Application Permission Concepts
- Client-Side Versus Server-Side Applications
- When Good Applications Go Bad
- Application Model Case Studies
- Quick-Start Tips
- 2. Mapping User Relationships with the Social Graph
- The Online Social Graph
- Applying the Real-Life Social Graph Online
- Sharing Private User Data: Opt-in Versus Opt-out
- Understanding Relationship Models
- Relationships Versus Entities
- Building Social Relevance: Exploring the Facebook Social Graph
- Defining Entity Likes and Dislikes Through the OpenLike Protocol
- Conclusion
- 3. Constructing the Foundation of a Social Application Platform
- 4. Defining Features with OpenSocial JavaScript References
- What You’ll Learn
- Including the OpenSocial Feature JavaScript Libraries
- Dynamically Setting the Height of a Gadget View
- Inserting Flash Movies in Your Gadget
- Displaying Messages to Your Users
- Saving State with User Preferences
- Setting Your Gadget Title Programmatically
- Integrating a Tabbed Gadget User Interface
- The Basic Gadget
- Creating a Tab from Markup
- Creating a Tab from JavaScript
- Getting and Setting Information About the TabSet
- Aligning tabs
- Showing and hiding tabs
- Obtaining the parent container
- Obtaining the currently selected tab
- Obtaining all tabs
- Removing a tab
- Setting the selected tab
- Swapping tab positions
- Getting and setting information about a tab
- Getting the callback of a tab
- Obtaining the content container
- Obtaining the tab position
- Obtaining the tab name
- Obtaining the tab label
- Extending Shindig with Your Own JavaScript Libraries
- Putting It All Together
- 5. Porting Applications, Profiles, and Friendships
- What You’ll Learn
- Evaluating OpenSocial Container Support
- Core Components of the OpenSocial Specification
- Cross-Container Development and Porting
- Porting Applications from Facebook to OpenSocial
- Personalizing Applications with Profile Data
- The Person Object
- Person Data Extraction Methods
- Fields Available Within the Person Object
- opensocial.Person.Field.ABOUT_ME
- opensocial.Person.Field.ACTIVITIES
- opensocial.Person.Field.ADDRESSES
- opensocial.Person.Field.AGE
- opensocial.Person.Field.BODY_TYPE
- opensocial.Person.Field.BOOKS
- opensocial.Person.Field.CARS
- opensocial.Person.Field.CHILDREN
- opensocial.Person.Field.CURRENT_LOCATION
- opensocial.Person.Field.DATE_OF_BIRTH
- opensocial.Person.Field.DRINKER
- opensocial.Person.Field.EMAILS
- opensocial.Person.Field.ETHNICITY
- opensocial.Person.Field.FASHION
- opensocial.Person.Field.FOOD
- opensocial.Person.Field.GENDER
- opensocial.Person.Field.HAPPIEST_WHEN
- opensocial.Person.Field.HAS_APP
- opensocial.Person.Field.HEROES
- opensocial.Person.Field.HUMOR
- opensocial.Person.Field.ID
- opensocial.Person.Field.INTERESTS
- opensocial.Person.Field.JOB_INTERESTS
- opensocial.Person.Field.JOBS
- opensocial.Person.Field.LANGUAGES_SPOKEN
- opensocial.Person.Field.LIVING_ARRANGEMENT
- opensocial.Person.Field.LOOKING_FOR
- opensocial.Person.Field.MOVIES
- opensocial.Person.Field.MUSIC
- opensocial.Person.Field.NAME
- opensocial.Person.Field.NETWORK_PRESENCE
- opensocial.Person.Field.NICKNAME
- opensocial.Person.Field.PETS
- opensocial.Person.Field.PHONE_NUMBERS
- opensocial.Person.Field.POLITICAL_VIEWS
- opensocial.Person.Field.PROFILE_SONG
- opensocial.Person.Field.PROFILE_URL
- opensocial.Person.Field.PROFILE_VIDEO
- opensocial.Person.Field.QUOTES
- opensocial.Person.Field.RELATIONSHIP_STATUS
- opensocial.Person.Field.RELIGION
- opensocial.Person.Field.ROMANCE
- opensocial.Person.Field.SCARED_OF
- opensocial.Person.Field.SCHOOLS
- opensocial.Person.Field.SEXUAL_ORIENTATION
- opensocial.Person.Field.SMOKER
- opensocial.Person.Field.SPORTS
- opensocial.Person.Field.STATUS
- opensocial.Person.Field.TAGS
- opensocial.Person.Field.THUMBNAIL_URL
- opensocial.Person.Field.TIME_ZONE
- opensocial.Person.Field.TURN_OFFS
- opensocial.Person.Field.TURN_ONS
- opensocial.Person.Field.TV_SHOWS
- opensocial.Person.Field.URLS
- Extending the Person Object
- Capturing the User Profile
- Using Friendships to Increase Your Audience
- Putting It All Together
- 6. OpenSocial Activities, Sharing, and Data Requests
- 7. Advanced OpenSocial and OpenSocial Next
- What You’ll Learn
- Data Pipelining
- OpenSocial Templating
- A Few More Tags: The OpenSocial Markup Language
- Localization Support with Message Bundles
- The OpenSocial REST API Libraries
- OpenSocial Next: Areas of Exploration
- OpenSocial and Distributed Web Frameworks
- Putting It All Together
- 8. Social Application Security Concepts
- What You’ll Learn
- Hosting Third-Party Code Through iframes
- A Secure Approach: The Caja Project
- Why Use Caja?
- Attack Vectors: How Caja Protects
- Setting Up Caja
- Cajoling Scripts from the Command Line
- Running Caja from a Web Application
- Running Caja with an OpenSocial Gadget
- Using JSLint to Spot JavaScript Issues Early
- Playing in the Caja Playground
- Tips for Working in a Caja Environment
- A Lighter Alternative to Caja: ADsafe
- ADsafe Versus Caja: Which One Should You Use?
- How to Implement ADsafe
- Putting It All Together
- Conclusion
- 9. Securing Social Graph Access with OAuth
- Beyond Basic Auth
- The OAuth 1.0a Standard
- OAuth 2
- OAuth 2 Workflow
- Implementation Example: Facebook
- Implementation Example: Requesting More User Information in the Facebook OAuth Process
- Implementation Example: End-User Experience
- Tips for Debugging Request Issues
- Conclusion
- 10. The Future of Social: Defining Social Entities Through Distributed Web Frameworks
- What You’ll Learn
- The Open Graph Protocol: Defining Web Pages As Social Entities
- Activity Streams: Standardizing Social Activities
- WebFinger: Expanding the Social Graph Through Email Addresses
- OExchange: Building a Social Sharing Graph
- PubSubHubbub: Content Syndication
- The Salmon Protocol: Unification of Conversation Entities
- Conclusion
- 11. Extending Your Social Graph with OpenID
- The OpenID Standard
- Do I Already Have an OpenID? How Do I Sign Up for One?
- The OpenID Authentication Flow
- OpenID Providers
- Bypassing Domain Discovery Errors in OpenID
- OpenID Extensions
- Simple Registration Extension
- Attribute Exchange Extension
- Attribute exchange types: Addresses
- Attribute exchange types: Audio and video greetings
- Attribute exchange types: Date of birth
- Attribute exchange types: Email
- Attribute exchange types: Images
- Attribute exchange types: Instant messaging
- Attribute exchange types: Name
- Attribute exchange types: Telephone
- Attribute exchange types: Websites
- Attribute exchange types: Work
- Attribute exchange types: Other personal details and preferences
- Provider Authentication Policy Extension
- Extensions Currently Under Development
- Implementation Example: OpenID
- Common Errors and Debugging Techniques
- Conclusion
- 12. Delivering User-Centric Experiences with Hybrid Auth
- The OpenID OAuth Hybrid Extension
- When Should I Use OpenID Versus Hybrid Auth?
- The OpenID OAuth Hybrid Auth Flow
- Implementation Example: OpenID, OAuth, and Yahoo!
- Application Setup: Getting Your OAuth Keys for the Hybrid Auth Process
- Implementing Hybrid Auth Using PHP
- Implementing Hybrid Auth Using Python
- Conclusion
- A. Web Development Core Concepts
- Glossary
- Index
- About the Author
- Colophon
- Copyright
It may not always be appropriate for a container to have an open-ended specification that caters to many different locales and requirements. In this case, building custom software to fit your needs can be a good approach. Doing so has a number of definite benefits for container implementers:
The software will be highly targeted for your container’s specific needs and requirements, thereby reducing code bloat and unneeded features.
The code base is divorced from the requirements of an open specification. This means that if a change is needed in the code that conflicts with the initial development specification, you can make that change without having to contribute it back to the open specification (and working to get it standardized in future versions) or having to maintain the code differences from the specification when you upgrade to new versions.
These are definitely powerful drivers for many development shops. You are building a project that exists within a silo, separate from the rest of the world. However, there are also a number of drawbacks to this approach:
You have to develop all code in-house or for the container itself. Since this is a proprietary code base, you’ll have to devote engineering time for all upgrades and new features.
The company must offer support mechanisms for developers building on top of the platform. The community of integration specialists on the particular platform will not include other companies or developers who have implemented a solution based on the same specification.
Facebook is one container that has a lot of its implementation built around proprietary technology developed specifically for its needs. We can see from its example that the proprietary approach can be very successful, but it takes a lot of effort, engineering, and development time.
In recent years, Facebook has begun integrating certain open source initiatives into its proprietary stack, such as the new OAuth 2.0 standard and the Open Graph Protocol, both of which we will cover in later chapters.
-
No Comment