Difference between FacebookNET and Facebook toolkit

Feb 9, 2008 at 6:06 PM
What is the Difference between FacebookNET and Facebook toolkit?
Feb 13, 2008 at 3:55 AM
Seriously, great question.

Whats the difference, which one has more effort behind it, etc.

Thank you,
G

http://www.hdgreetings.com
Feb 13, 2008 at 8:03 AM
I think that real question should be why these projects dont merge into one?
Feb 13, 2008 at 3:42 PM
Great question.

Is the answer that everyone has "Not Invented Here" syndrome, or an ego thing, or a power/control thing?

We really don't need an HD-DVD vs. Blueray Situation here.

Feb 14, 2008 at 6:46 PM
Has anyone done a even a comparison of pros and cons of each?

Without even a comment from the developers here it doesn't inspire great confidence.
Feb 15, 2008 at 7:54 AM

Greetings wrote:
Has anyone done a even a comparison of pros and cons of each?

Without even a comment from the developers here it doesn't inspire great confidence.


Why don't you try both and post what you think are the differences? Why would a developer on this project comment on the pros and cons of each? If I thought there were cons, I'd just add some new things to fix it. Not trying to be rude, but why should someone else tell you why A is better than B. I think it would be best for you to try both and decide for yourself. They are obviously two different approaches to doing development. IMO 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.
Feb 15, 2008 at 2:57 PM
>>Not trying to be rude, but why should someone else tell you why A is better than B

Because it is common practice when entering a community to find out what has been discussed to death, and what hasn't. Without establishing this it wouldn't be cool for me to come out here and "proclaim" my opinion without even researching what existing comparisons exist. That's why.

If you are telling me you know of no comparisons done, yet I can see there are other people here looking for answers, then yes it should be done by someone, maybe me.

One thing for sure, it should be discussed. Many people are confused about it evidenced by their questions. Also if people are going to contribute to a project by helping test, debug, and possible contribute code, why shouldn't they hear from it's developers on why it's the best effort to join? MANY open projects have pages where the creators make their case for the project, it's benefits, advantages, and their vision and hopes for it in the future.















Feb 16, 2008 at 11:10 PM
Have some new information on Facebook.Net.

Looks like it does support other scenarios like desktop as well as web, also:

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 bad from a framework design perspective)
FacebookNET.Desktop.dll - desktop app specific stuff (eg. Login dialog)
FacebookNET.dll - shared stuff (all the service apis)
Facebook.NET doesn't use a server-side session which leads to unscalable apps, and apps that don't work well on server farms. It uses things like control state.

So far it looks like Facebook.NET supports everything Facebook Toolkit does, with the advantage of not using session state, and not encouraging deriving from special base classes.

Of course this is on-going so if you know of any benefit or advantage that Facebook Toolkit has over Facebook.NET please let it be known.

Also please remember this is not an attack on the Facebook Toolkit. I don't know guys on either project and have no vested interest. Clearly a look of good work has gone into Facebook Toolkit and that is not disputed. This digging is only because many people have been asking these questions.

Feb 17, 2008 at 10:48 AM
I started this post and didnt know that it would be helpfull that much.


check this out guys :
http://www.facebook.com/apps/application.php?id=7827545237

I have done this application using Facebook toolkit.
Feb 21, 2008 at 8:40 PM

More information comparing Facebook.Net with the Facebook Toolkit:
http://www.marketing-ninja.com/?p=131

This also strongly recommends Facebook.Net.

Keep in mind this was written in August 2007 and of course software can evolve.


Feb 22, 2008 at 3:24 AM

Greetings wrote:
Have some new information on Facebook.Net.

Looks like it does support other scenarios like desktop as well as web, also:

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 bad from a framework design perspective)
FacebookNET.Desktop.dll - desktop app specific stuff (eg. Login dialog)
FacebookNET.dll - shared stuff (all the service apis)
Facebook.NET doesn't use a server-side session which leads to unscalable apps, and apps that don't work well on server farms. It uses things like control state.

So far it looks like Facebook.NET supports everything Facebook Toolkit does, with the advantage of not using session state, and not encouraging deriving from special base classes.

Of course this is on-going so if you know of any benefit or advantage that Facebook Toolkit has over Facebook.NET please let it be known.

Also please remember this is not an attack on the Facebook Toolkit. I don't know guys on either project and have no vested interest. Clearly a look of good work has gone into Facebook Toolkit and that is not disputed. This digging is only because many people have been asking these questions.




You really need to be able to establish your own opinions and not just copy and paste other people’s thoughts i.e. directly from Nikhil’s response to you. It’s also ridiculous that you just cut and paste my previous response to you into a thread to Nikhil. If I said that the Facebook Developer Toolkit was more environmentally friendly would you have just pasted that in response to Nikhil’s question?

The values are stored in session and not control state because we didn’t go the server control route like Nikhil did. The data we store in session is limited to a few items and it does actually work well on server farms. I have a current FB app using the toolkit that operates quite happily on session state servers. It’s not as if control state is infinitely better. That data much always be round-tripped with each page load so it’s not without some trade-off, albeit small depending on the amount of data stored. Sure, if you’d like to turn session off on your webserver than Facebook Toolkit is not going to work for you.

I also don’t think the concept of a FBML base page to inherit from is completely crazy or messy. To me it’s creating a specific type of page that has the necessary Facebook properties.

Maybe the decisions aren’t the best in hindsight, but that’s the way it was built and it works well IMO.

Do you personally know what the difference between control state and session state? Have you personally built scalable ASP.NET apps on web farms? I’m not going to debate with Nikhil via you since he actually built parts of ASP.NET and if says his architecture is better than it’s better.

But seriously, WTF? "if you know of any benefit or advantage that Facebook Toolkit has over Facebook.NET please let it be known."

I just don't understand you expect from trying to drive out this comparison between projects? Should we just delete this whole project so there is only 1 toolkit for building FB apps in .NET? Should we just copy all of Nikhil’s code into this project and go from there? Are you just trying to make me feel sad that other people think code I contributed is an un-scalable mess?

I will let it be known that our recursive quantum encrypted memory heap allocation algorithm is 80% to less vulnerable to buffer overflow than Facebook.NETs.
Feb 22, 2008 at 3:29 AM
I just want to address a few comments in this thread and then I can give you an overview of this project and some background info that might be helpful. This is going to be a long post so you may want to grab some snacks and a beverage.

In regards to this comment "Because it is common practice when entering a community to find out what has been discussed to death, and what hasn't. Without establishing this it wouldn't be cool for me to come out here and "proclaim" my opinion without even researching what existing comparisons exist. That's why."
I think this comes down to you doing your own research. If the issue has been discussed to death then I think you'll be able to find it searching via codeplex discussions, browsing the threads or searching an public info on Google. People should feel free to proclaim their opinion if they have something insightful to add to the discussion. No one is going to discourage that. I just don't think a discussion forum on this project is the place to debate "Why should i use this over the other toolkit". That really IS NOT helpful IMO. People contributing constructive feedback, testing and ultimately contributing code to the project IS helpful.

Furthermore, I don't really see why it's important for someone to tell you why one is better than the other. If I tell you that the Facebook toolkit is more scalable than Facebook.NET, is 10x faster in my benchmarks and improves developer productivity then are you just going to use it because I said so? It comes down to what is a better experience for you. You are the one writing the code. So what if AJAX Ninja doesn't like it. Use whatever makes you more productive and allows you to build an app that works. With even a small effort on your part you could build a quick sample app and try out each.

Or you can be like this guy: (http://kpumuk.info/facebook/what-the-fuck-are-developers-of-facebook-client-libraries-for-asp-net-stupid/) “I have posted a bug to the tracker and decided to look at the Facebook.NET, a better and much cleaner implementation according to AjaxNinja.”

Specifically in regards to Marketing Ninja / AJAX Ninjas comments, I've just built an application using the toolkit that is all FBML and uses the base page. Everything works fine and I haven't had issues. I understand his points but I disagree with them (except the documentation issue). Obviously there is a lack of comprehensive samples and documentation, but I think it's unfair to criticize something just because you don't understand how it works. Could Facebook Developer Toolkit be better? Of course. If I started over I'd write a ton of stuff differently, but in my experience it works well for a variety of scenarios. Unless you are the greatest developer in the world, there are always things that could be done better. If you value AJAX ninja's opinion and want to use Facebook.net then go ahead. I'm not concerned that he prefers Facebook.NET since I don’t find his blog an informative or insightful place for ASP.NET info. If it works better for him then that's great.

As far as convincing people to join, I don't feel like I or and any of the people on this project need to do that. If you want to join, it should be because you found this code useful or you are enthusiastic about the opportunity to make it better as part of a community development team. We're not selling a product here. It's free. Use or don't. I'd love if there was a huge community of developers really excited about working on this and making something great, but I don't want to spend time creating marketing info of why this project is better than Facebook.NET.

I do recognize that documentation and educating developers is an area for improvement. To help alleviate some issues with using the toolkit, my goal is to write a sample application and guide to building apps (including configuration in FB which seems to cause a lot of the problems I've seen people encounter). I'd like to do this sometime in the next month or two, but this is a volunteer effort on my part so it comes down to when I have free time.

Regarding “I think that real question should be why these projects dont merge into one? “ and “Is the answer that everyone has ‘Not Invented Here’ syndrome, or an ego thing, or a power/control thing?” Kind of a backhanded question, but I’ll respond. I did email Nikhil and asked him about combining efforts and he declined.

He said: “Thanks for contacting. I learned about your dev kit after starting to work on an app on my end from which this project came about. ….
In looking at both projects, I think we have fairly different approaches/design, so I am not sure combining would be simple/possible. My intent is to continue keeping Facebook.NET optimized and representative of the asp.net model.”

I really respect Nikhil as a developer and I understand his desire to pursue a different route with his project. In case you aren’t aware, Nikhil is a software architect in the .NET Developer Platform group at Microsoft. He has been responsible for much of the architecture in ASP.NET like server controls and built several of the server controls that ship with the product. He’s also authored probably the definitive book on building ASP.NET server controls and components. Facebook.NET is the implementation of the Facebook API using server controls. It follows the pattern of many of the server controls like ObjectDataSources that you may be using. We did not originally develop this toolkit in that server control model and I can address that on page 4 in the history of the project section.

Obviously Nikhil knows more about ASP.NET and server control development than I or most likely any contributor to this project will ever know so I’m confident that the code is solid. Even if he just came out and said “Your code sucks, I want nothing to do with it”, I’d be fine with that. It’s Nikhil Kothari, he knows his $hit and I respect his decision.

As for other differences, this is just my opinion, but Facebook.NET seems to be a mostly a solo development effort. Nikhil is the only person listed in the People section on the project and he encourages bug submission or feature suggestions rather than contributing code. I think with this project we are providing an opportunity for all developers to get involved. I’ll be the first to admit that Nikhil’s code is probably better, but in the end I think the Facebook Toolkit works well for building FB apps and I enjoy using something that I helped create. So why should you use this? Because you have the opportunity to write code that other developers – your peers- are going to use. To me that is a really cool experience and it helps me improve as a developer. (Well it’s fun until people just b*tch that the code sucks or this other project is better, but that is another issue). I encourage everyone that uses the code in this project to try and incorporate something back to the code base. If you just want to build apps using the server control model with someone else’s code then you should use Facebook.NET.

So who am I and why did I spend an hour writing this? My name is Kevin Marshall and I work for Clarity Consulting. A few months before the f8 platform launch, someone from Microsoft contacted us about an idea to build a .NET wrapper for the Facebook API. The goal was to build something simple for beginning developers – most likely in the college – to use in their projects. Facebook seemed an ideal target because most of that group was probably already using Facebook. Keep in mind that this was before the platform launch which means that you could not build applications into the Facebook site – You could only make calls to the API and retrieve info like a list of friends and their photos. The original scenario we designed was: Developer installs Facebook Toolkit, opens Visual Studio Express, creates a new win form project, drags a friend list control from the toolbox onto the form, sets the API key/secret in the control properties, runs the app and voila – you just built a desktop application to display your friends from Facebook. Optionally, you could write about 4 lines of code in the code behind for a form, add a grid or some data presenter control to the form and bind the results collection from something like GetPhotos to that grid or control. The goal was to give new developers some fun building blocks to get started in building applications. It handled popping login dialogs and controlling authentication to FB so you really didn’t have to do anything. This would allow novice developers to create screen savers of FB photos or maybe a small system tray app to popup friends’ status messages. The FB toolkit was going to be one of variety of such building blocks available with VS Express. This is not to say that the API was dumbed down at all for people, but our main focus was making the desktop dev scenario relatively simple but still allow for more advanced coding if needed. Microsoft helped to bootstrap this effort with Ryan Powers and I doing most of the original development.

Initially we chose not to build web controls because there didn’t seem to be a great use case. Why build something to display a list of friends on the web when there is already a great app for that, Facebook.com? Ultimately we added this scenario so that developers on VS Express Web could have these same blocks when building web apps and not be left out.

(Continued in the Next Post)
Feb 22, 2008 at 3:33 AM
Around the f8 launch we worked with Microsoft to make all the code available on CodePlex so it could evolve as an open source effort. (Kudos to Microsoft for doing that by the way – people knock them for being closed but it was really cool that they’d jumpstart this project and support a community development model)
Post f8 launch there was some interest in extending the toolkit to support the new platform model. At that time the FB platform was pretty volatile and no one was using ASP.NET since all the documentation and libraries from Facebook were centered on PHP. I don’t think at the launch event I realized how much excitement there would be in building FB platform apps. I mean I saw stuff like Superwall and Fortune Cookie. I was obviously wrong, but it didn’t seem like that would turn into the biggest tech story of the year. Since the release on CodePlex about a dozen other developers in the community (i.e. not from Microsoft) have contributed to build-in support for the platform. Maybe this project would look different if it originated a toolkit for building FB platform apps in ASP.NET, but I do think the support that exists currently is quite good.

So that is the history of this project and maybe helps explain some early design decisions in v1.0. This is not the “Official Microsoft Facebook Toolkit” as some people have dubbed it. It’s an open source project that Microsoft helped to jump start with some work from Ryan and I at Clarity. I think the distinction is important when people complain about bug fixes or lack of documentation or criticize Microsoft’s level of support. This is NOT a shipping product with support and warranties. It’s a community effort. It comes with all the risks and rewards of using open source code.

From CodePlex:
“Microsoft does not control, review, revise, endorse or distribute the third party projects on this site. Microsoft is hosting the CodePlex site solely as a web storage site as a service to the developer community. For more information, read the CodePlex Terms Of Use.”

As for where this project is going, maybe this post inspires some people to get involved and contribute. Or maybe you stop looking at this discussion altogether. We could use some people to step up as developers / coordinators.

I’d really like to get more involved again but I see crap like:

What the fuck? Are Developers of Facebook client libraries for ASP.NET stupid? (http://kpumuk.info/facebook/what-the-fuck-are-developers-of-facebook-client-libraries-for-asp-net-stupid/)

or some similar comments on this discussion board and it just kills any motivation.

-kevin
Feb 22, 2008 at 4:38 AM
Kevin it seems about half of your post was very useful information. Talking about the technology used in the project, the history, how things came about. All of that was great.

Another part was you complaining about recent criticism or perceived criticism. I don't think that is productive but I think you're entitled to vent and it doesn't really hurt anything, so be it.

A final part was personal attacks on others including myself just because we're asking questions and exchanging information.

One example, you implied I'm a novice web dev by asking if I even know the difference between control state and session state. And "have I ever even worked on a scalable web application". It wasn't the questions, it was your tone that was condescending and rude.

I don't think you really are interested in my resume, and I'm not insecure enough to need try provide my resume here as defense. However if I did I doubt you'd still feel so superior.

All I want to know is was this a once time occurrence, or is this how you normally deal with adversity, criticism, and what you perceive as wrong doing by me or others here?


Feb 22, 2008 at 7:09 AM
I apologize if my tone was rude. My point was not to belittle but rather to push you to develop your own opinion. You posted Nikhil's responses as if you had used the FB Toolkit and established some findings. That's not the what happened. I'm asking do you understand those concepts and believe those things to be true. I mean if you have experience building highly scalable .NET apps and you think the code here doesn't allow that then I think it's reasonable to have a discussion about how the project can be improved. Do you think it's bad to derive from a base page? If so why? What would you recommend instead? Do it exactly like Facebook.net?

Obviously, I am defensive. Let's look at your history of comments:

"Without even a comment from the developers here it doesn't inspire great confidence."
- I mean right off the bat you knock us just because no one responded to your question when.

"Is the answer that everyone has "Not Invented Here" syndrome, or an ego thing, or a power/control thing?
We really don't need an HD-DVD vs. Blueray Situation here."
- So basically you imply the developers here of either having an ego or wanting to be a tyrant when really you had no context for the history. Or really any thoughts on why they should merge? Should there be only 1 open source project for every specific project? Why doesn't doesn't HDGreetings just merge with Hallmark? Why do we need another greeting card site?

"if you know of any benefit or advantage that Facebook Toolkit has over Facebook.NET please let it be known."
-You're pretty much saying "I can't think of any reason why you'd use this, so someone tell me" - Right there you are even asking anyone here to defend why this project is worthwhile.

"So far it looks like Facebook.NET supports everything Facebook Toolkit does, with the advantage of not using session state, and not encouraging deriving from special base classes."
Even your summary of why you err Nikhil thinks the other project is better, how is that constructive? I'm all for having a discussion of how to make this project better, but that's not what you are doing.

Finally you the Marketing Ninja link without really any added value or analysis of your own. Do you agree with his assessment? That whole blog post was kind of a slam on this project and then you present it as further evidence why the other project is better. I really don't see how that's helpful. What would be helpful is something like "Some people are struggling to make FBML apps using the toolkit, I think we could fix that by doing x & y"

Basically what are you trying to accomplish? To get me or someone here to convince that this project worthwhile? Do you hope to have everyone stop using this and move to Facebook.NET if it's better? I don't really get why you're so determined to have other people tell you which is better or have some established list of pro's and con's in THIS forum. If you want to try them both out and then write a blog post that's great and probably helpful to others.

It's not like I don't think there aren't things that could be better or some bugs to be fixed, it's just a matter of finding time. If my full-time job was to build this toolkit it would probably be better. It's not though. Obviously I wasted like 2 hrs on this thread today when I could have just wrote some code, but I was catching up the discussion threads to come up with some ideas for the next release. Why should I spend time on this project if the majority of the feedback is negative? It's just de-motivating. I would think it would be the opposite - like if you want someone to write good code for you for free, it's helpful to be encouraging.

I think most people react negatively to criticism, but they react well to constructive criticism. There is a big difference between. I really don't see any well-reasoned constructive criticism from you and most of your comments tend toward just criticism.

I'm sure you're an amazing developer and better than I am. It would be awesome if you'd contribute some improvements to the code otherwise I'm not really looking for someone to just point out problems.

I'll just leave it at that and not comment further in this thread.
Feb 22, 2008 at 2:34 PM
Kevin thank you for that post.

I think your points are valid in that:
- I agree my fact finding was a lazy approach by trying to cross-pollinate information rather than do primary investigation
- Some of the phrasing was provocative when it didn't have to be, especially throwing out the ninja blog

Although I can't excuse these points I can assure you they were born out trying to shortcut time rather than trying to be disrespectful. It seems there just isn't a time shortcut here and of course, never any reason to disrespect someone publicly.

If either FB efforts have some flaws well thats true of all projects right? Every piece of code written can be better with n more revisions or more time. We just make trade-offs based on resources we have and guesses about what users will need.

I guess my true motivations are wishing that the FB efforts had as much momentum or as many volunteers as some of the PHP efforts.

Please continue any posting you feel like when you have time - there are no haters here.
Feb 22, 2008 at 3:38 PM
Hi Kevin,

My frustration is that there is no "official Microsoft" wrapper for Facebook's API. Especially now that MS has invested $$$ in f8, I'm looking to MS to provide some leadership here.

For instance, f8 just did another push and now I'm seeing parameter errors in the wrapper class. Does f8 care that their push might break your MS wrapper? You, Kevin, probably care but where's the resources from MS for you to respond to it?

Thanks for explaining the history behind your efforts and I appreciate that the bits are available on Codeplex.

-Sean

Feb 22, 2008 at 4:52 PM
First of all I want to say that I apreciate very much the effort behind the Toolkit.

I hope that there is a solution to the problems of lack of resources. Not beeing a very talented developer (to be honest: I'm no developer at all, rather a PM who does some coding in his spare time) I don't think that I can help that much, besides some coordinating maybe.

A issue is the frequency of changes in the FB API. I'm not sure if a small C# volunteers community can handle this. Microsoft does use Facebook to promote the VS products. So it would be more than wise if they would reactivate their help for the product.

At the moment, the F8 community is widely dispersed. I'm not the only one who publishes some information on a separate website (http://www.f8info.com/). Partly because of the limitations of the CodePlex platform. A common platform for all of us could help to get a stronger voice (especially when dealing with MS and F8) and to improve visibility. If anyone is interested to discuss such an idea feel free to contact me.

Kevin, thanks again for you efforts - and we all hope that the Toolkit won't die because of lack of resources or motivation.

cheers,
Ueli
May 31, 2008 at 7:35 PM
Considering the last release was in January, I am not sure this toolkit is the best way to go.  I've looked at Facebook.NET, and it is does not appear to be very trustworthy either. Could I just use facebook's REST API, raw so to speak :) ?  How would one go about developing a Facebook app in .net without toolkits? If someone is doing this, any examples would be greatly appreciated!

Best,
Alex
Jun 1, 2008 at 11:21 AM
Edited Jun 1, 2008 at 11:23 AM

miller50 wrote:
Considering the last release was in January, I am not sure this toolkit is the best way to go.  I've looked at Facebook.NET, and it is does not appear to be very trustworthy either. Could I just use facebook's REST API, raw so to speak :) ?  How would one go about developing a Facebook app in .net without toolkits? If someone is doing this, any examples would be greatly appreciated!
My first Facebook canvas application used autogenerated (using sample XML requests and responses from the Facebook developer wiki) XMLSerializer-decorated classes for the communication, and wrapped each API call in a method which used the appropriate de/serializer. Then a base HttpHandler took care of the stuff Facebook sends in the canvas form (user id, friends list, etc). This is easy to cook up, but the problem is that it quickly starts to look alot like the two general-purpose Facebook.NET projects here on Codeplex, so why bother if the result is the same? People are complaining about slow responses to Facebook API changes, even though anyone can make these changes to existing projects and submit patches.

There's also a specialized Facebook "toolkit" here too, that focuses on "true asynchrony".

Instead of merging everything, I'd like to see more specialized and less all-purpose projects. Why not a Codeplex project for just the API communication, a different for the ASP aspect, etc? Maybe I want both asynchronous communication (which jdconley's project can give me) but visual web designer controls I can drag and drop (which at least one of the other projects can give me).