Should FacebookNET and Facebook Toolkit merge?

Feb 13, 2008 at 3:47 PM
Ok this is the hard question for the creators but the important question for developers.

Why not adopt the best approaches from each?

Please also see the similar thread on the FB Toolkit forumL
http://www.codeplex.com/FacebookToolkit/Thread/View.aspx?ThreadId=21843

Thank you,
G


http://www.hdgreetings.com
Coordinator
Feb 14, 2008 at 5:46 AM
Edited Feb 14, 2008 at 4:46 PM
Please post the best approaches/compelling aspects of Facebook Toolkit here - I'd love to hear what they are.

There are differences in the models adopted by the two projects, as well as in the api design - so merging without causing api breaking changes/usage changes for users of either project isn't simple... however merging at the scenario level is much more plausible; hence I am all ears to hear what works well that should be considered in the context of Facebook.NET.
Feb 15, 2008 at 6:31 PM
Edited Feb 15, 2008 at 6:32 PM
...
Feb 15, 2008 at 6:31 PM
>>Please post the best approaches/compelling aspects of Facebook Toolkit here - I'd love to hear what they are.

Ok here's what I've heard so far:

>Facebook.net mimics the server control architecture in asp.net. You just drag and drop items onto your page and set some properties. It has FB Data Source
>sliek SQL DataSources. Facebook Developer Toolkit works more like traditional API methods to call. I think it works well in variety of situations like desktop apps,
>mobile, web services etc. Instead of server control you can inherit your pages from base facebook pages to manage session.

Not sure what is meant by session - like asp.net session of a FB specific concept of session.
Coordinator
Feb 16, 2008 at 5:10 AM
Edited Feb 16, 2008 at 6:14 AM
Facebook.NET supports both desktop and web apps.
FacebookNET.Web.dll - asp.net specific stuff (FacebookApplication server control - manages facebook session etc. no need to derive from base pages, which is messy, and generally not suitable from a framework design perspective)
FacebookNET.Desktop.dll - desktop app specific stuff (eg. Login dialog)
FacebookNET.dll - shared stuff (all the service apis)

Speaking about session, Facebook.NET doesn't use a server-side session to track things. Session can be expensive, and potentially lead to unscalable apps, or apps that don't work well on server farms. Instead Facebook.NET uses things like control state.

Based on the things you mention so far, either the support already exists, or they aren't there because they're not necessary or aren't the best approach.

Keep the discussion going...
Feb 21, 2008 at 6:38 PM
Edited Feb 21, 2008 at 6:38 PM
Here's a blog entry that has one guy's comparison of the two frameworks: http://www.marketing-ninja.com/?p=131

If any Facebook frameworks for .NET were to merge, I'd prefer Nikhil incorporate fbasync http://www.codeplex.com/fbasync. I haven't tested it out (seems crazy to build a production application on an inactive project) but the idea behind it seems killer.

Have you taken a look at it, Nikhil?

Bill
Coordinator
Feb 24, 2008 at 7:16 AM
I know I need to add async support. One of the reasons I factored out the API calls into multiple service objects is to not create a monster service class with lots of methods (which would triple with Begin/End variants to support async).

Async is not impossible either - it is in fact implemented for creating auth tokens, and sessions for use in desktop apps, so that things like the login dialog do not freeze.

Using async support in asp.net apps however is non-trivial. If all you need to do is make one async call to Facebook per request, it is not so bad - you register an async task with the page, and asp.net does all the right things underneath the covers, and resumes the request pipeline at the right time. However this gets quite complex if you need to make multiple calls, esp. calls where the 2nd one depends on the next one.

Facebook has also introduced a batching mechanism, and pre-fetch data mechanism, where you can do multiple things at once, or have facebook send the data you know you need in the initial request - both of these would be much more useful than async in relative priority in my opinion, and perhaps async for the batched calls, and FQL queries is the first step, rather than for every api.

Facebook certainly evolves very quickly...
Feb 25, 2008 at 7:05 PM
Oh sure, batching and prefetching would be far better than asynchronous support on the ASP.NET side. The biggest performance bottleneck for Facebook apps isn't rendering the page but getting the data from the Facebook cloud over and over. I had seen the batching support, but I wasn't aware of prefetching.

Thanks for staying on top of this!

Bill