Facebook Client Library built on Script#

Facebook's latest offering to application developers - a client-side script API, built on Script#!

While developing Facebook.NET, it was on the back of my mind to create a script library equivalent in script# for client-side only interaction with the Facebook REST API using the existing JSONP interface to their REST service. I didn't do it yet for security reasons, as it would require sending down both the application key and secret to the client (something that existing Flash and Silverlight examples unfortunately and incorrectly show). Instead I opt'd for creating a Facebook Proxy service that allows your client code to talk to facebook via your service in an almost transparent manner. Those of you who have downloaded Facebook.NET can see a sample of this.

Now Facebook is offering a client-side SDK. Wei Zhu blogged about the JavaScript Client Library for the Facebook API on the official developer blog last Friday. If you're a Facebook application developer, you'll want to check this out.

Wei Zhu has been a long-time supporter of Script#, and it makes me super excited to see that the library itself was coded in Script#, and also uses the Script# runtime as part of its implementation. I am sure Script# usage resulted in some substantial productivity gains, and makes me hopeful that this will spike some more interest in the technology. Its also exciting to see the potential for a number of Facebook apps built on top of this. I am hopeful that Facebook will eventually release the .dll version of the script, so other downstream users of Script# will be able to directly reference these APIs in their C# code, without having to create a stub metadata dll

I also chatted with Wei during the weekend about possible security implications. It looks like they've thought through the implications. Specifically, you only need to publish the API key (which is public anyway), and the client library connects with Facebook to generate a temporary user-session scoped secret using some new services, so you don't have to publish your actual secret. Nice!


[ Tags: | ]
Posted on Monday, 1/28/2008 @ 8:28 AM | #Script#


Comments

11 comments have been posted.

Bertrand Le Roy

Posted on 1/28/2008 @ 12:19 PM
Congratulations! If that's not mainstream adoption, I don't know what it is...

rute

Posted on 1/28/2008 @ 2:58 PM
great!

Michael Sync

Posted on 1/28/2008 @ 7:13 PM
Wow! that's great....

BTW, you told me once that there is ext-JS Script# version in Google Code. I was searching this code for long time but I'm not able to get the link. It would be great if you can pass the link where I can download the ext-JS script# version. Thanks in advance.

Nikhil Kothari

Posted on 1/28/2008 @ 9:20 PM
Ext# is at http://code.google.com/p/extsharp/

Phillip

Posted on 1/29/2008 @ 12:09 PM
What's to stop someone from using your public api key to make api calls on your apps behalf?

Erick Landeros

Posted on 1/29/2008 @ 7:08 PM
When will the next releases be compiled?

Nikhil Kothari

Posted on 1/30/2008 @ 12:36 AM
Erick - let me know if you're looking for something in particular. There are always some things in the works, so stay tuned for the next release. Couple of interesting things in the works currently.

Phillip - as mentioned the app key is public - what is new is a per-user temporary secret. However, you're welcome to ask about the security implications on the Facebook blog, or developer forum.

AjaxProdigy.com

Posted on 2/6/2008 @ 10:32 AM
I recently heard that facebook was making it so they're widgets and things can placed on another website like a myspace for example.They would use javascript to insert the gadget and ajax to update it.

winer457

Posted on 2/11/2008 @ 2:13 AM
I recently heard that facebook was making it so they're widgets and things can placed on another website

Márcio Duarte

Posted on 3/15/2008 @ 9:06 AM
I post this in the CodePlex discussion session of the Script# project. I'll replicate it here to enhance the visibility... :D

You talk about Ext#. Its a great idea, but not applicable in real world project...

I'll explain: The Ext# is not very portable... I can't create a custom control and encapsulate a Ext grid, because I'm unable to pass a Array (or another Object to represent my data set) in the Dictionary args argument in the Main method of the Ext# class.

Why??? Its not Ext# fault... Sorry to say, but the problem is in Script# (or its my fault and this post its my desperate movement to understand what is it).

The ScriptLet control has a property Arguments that is a Collection<ScriptletArgument>. There are only 6 types of ScriptletArgument: BooleanLiteral, ControlReference, ElementReference, NumericLiteral, ScriptLiteral and StringLiteral.

All of then, the only with possibilty to complete my objective is the ScriptLiteral, but I´ll need to create a JavaScript function to translate my C# Object and this is not a kind of facility that I want in my framework.

The next step is to extend. I create an ObjectReference class inherits form ScriptletArgument. Ok, but there is no way to instatiate an ObjectReference object because the constructor of ScriptletArgument is INTERNAL!!!!

So, my questions are: Why this is internal??? Why we need to wait at v1.0 to get the source code??? While we wait, can you turn the ScriptletArgument ctor to public please??? Or create more ScriptletArgument derived class to attend the new concepts introduced by Ext#???

Please?!?! :D

Best Regards.

Nikhil Kothari

Posted on 3/21/2008 @ 7:48 PM
Márcio, I posted a reply to your comment on the codeplex discussion forum.
The discussion on this post has been closed. Please use my contact form to provide comments.