Facebook vs. MySpace/OpenSocial Development

After having looked at MySpace's OpenSocial implementation I wanted to provide a comparison between it and the Facebook development platform. They are based upon completely different models and moving from one to the other is not as easy as one would hope.

Here's what's different in MySpace's Open Social Development Platform from what I've seen using the Facebook/Bebo platform. Where the items are known issues I have indicated as such. Some of these items have been derived from research and some from the MySpace forums. I have given links where available.

1. Your MySpace application code is hosted on MySpace servers, NOT YOURS. There is no callback URL that you can provide that MySpace can use to call back to your server.
2. It appears that the only way to communicate with your own server from your MySpace app is to use the makeRequest() API call.
   • Currently this is ONLY supported for endpoints running on port 80! Out of luck if your development server runs on a different port.
   • Supposedly MySpace is going to open some ports in a higher range to alleviate this issue. This is really, really frustrating.
   • "MakeRequest gets around the XHR cross-domain restriction by utilizing a custom http proxy hosted by MySpace. This proxy relays incoming requests to other sites and pipes the results back to the browser. It also optionally signs the requests using the OAuth methodology…It is important to note that this is not a standard open proxy--it does its best to verify that the request came from a valid OpenSocial application hosted on MySpace." from MySpace Developer Docs
   • Maybe only able to send as GET params - unknown how to send as POST variables
   • Currently only working on some URLs (does not work for http://www.google.com for example – known issue)
   • Currently only returns responses in uncompressed format (known issue – they are working on this one)
   • MySpace will be providing an 'App Data' 'something' to store application data but this is currently unavailable.
3. Currently the only way to actually get code into your MySpace app is to paste it in a ridiculously small textarea control on the app profile page. Seriously. And doing so results in:
4. Currently every time you update the code in your app it puts a NEW copy of the app on the respective page. Known Bug.
5. During the 'sandbox phase' (length unknown) of the MySpace Development Platform only friends can add apps
   • Only 3 installs of any given app allowed
   • If not a friend, cannot see app
   • There is no directory of apps yet
   • Have to log in as the app (because you have to use a unique email address for each) and friend people as that user in order for them to see and add it
   • More details here.
6. There are no callbacks for any application events (post-add, pre-remove, etc.)
7. You cannot encrypt or obfuscate your JavaScript code per the MySpace TOS…
8. There is no datastore support
   • The only way to persist data is to pass it to your server using the aforementioned makeRequest call
   • Must use oAuth to ensure that the data is correct
   • Saw that it could be possible to use Google's Base API (http://code.google.com/apis/base/starting-out.html#insupdel) to do this…
9. There are 3 different places the app can be installed into a user's profile, height is modifiable (to some degree?), but NOT width
   • Home page
   • Profile page
   • NOTE: any portion of your MySpace Applications and MySpace Application Content that will appear on a MySpace Profile must not:
     • contain or create an <iframe>
     • cause their containing <iframe> to be navigated to new location, for example, by using JavaScript code, form posts, or containing links;
     • contain or create <script> tags pointing to external sources except those that are explicitly allowed; and
     • contain or create links to external CSS style sheets.
   • Canvas page
10. Your app code always runs in an iframe (provided by their container I guess).
11. There is no formatting language (like FBML) or controls available other than straight (D)HTML. Kind of strange, this one. Facebook uses FBML that it converts to HTML (on its side) which it then pumps to the user's browser. Profile data can be cached on their servers. Very speedy. Could be me but it looks like MySpace is going to require all of your JavaScript to be executed on every refresh of the page – add to that a few calls back and forth to the container/ your server… What is going to happen to MySpace when there are 20 apps installed on each person's profile? Ewwww.
12. All your JavaScript runs under/is subject to manipulation by Google's Caja; this may limit what your JavaScript can do but makes it safer for MySpace to run 3rd-party scripts. This could slow your JavaScript down as Caja may modify or restrict it.
13. No/very limited support for 3rd-party JavaScript libraries so far; unknown when more will be available. Appears that jQuery is available based on this post. But if you have existing Facebook code that heavily uses Prototype/Scriptaculous/mootools/EXT/YUI/et.al. you are going to have a lot of reimplementation to do!
14. Perhaps I am confused but there currently appears to be no obvious/legal way to go from one page of your application to another (from profile->canvas for example). There is an API for this (requestNavigateTo()) but it's not implemented yet. TOS explicitly forbids redirection of the browser window.
15. No popups are allowed – not sure if this would include Facebook-style AJAX dialogs and their ilk or if this just means browser popup windows. Facebook also disallows popups but does have the FBJS Dialog object available.
16. oAuth is required to ensure that the user making the request from your MySpace application is valid/trusted. See this post. I am not sure if this API's behavior is fully baked yet, though.