lack of release is killing fb, while fbconnect usage soars.
| Project: | Drupal for Facebook |
| Version: | 6.x-2.x-dev |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
I got involved with this module when it first came out, helping with the documentation, and though my participation has been absent since then, I do think this is a great module, and the concept of using drupal to power a facebook application is very powerful. BUT, since January, when fbconnect module came out, it's number of implementations has grown steadily, with a base of 1,500 installations in a beta. The 6.x branch of Drupal for Facebook on the other hand only hit in March, right before DrupalCon. Excitement was high, and Dave won a knight foundation award then, to continue development, but a release has been elusive. fb usage plateaued in September, and has actually started loosing installations since then. and now has only about 150 installations.
My client needs the basic facebook connect functionality that fbconnect provides, and I'm facing the same decision that thousands of others have had to make. Do I use fbconnect or D4F? Most users are going to go for fbconnect because that is the name they are looking for, has a beta release, and has thousands of installations. I'm not posting this to place blame, but to highlight this issue to those that care about it, and encourage the the discussion on what to do.
#1
Here is a related post of someone's experience using fb. (it wasn't very positive) http://groups.drupal.org/node/24867
#2
here is yet another module that uses the facebook api. http://drupal.org/project/facebook_stream
#3
frank, you fail. please note in your documentation where you're providing it so i know where to give it due respect.
you fail to understand the very substantial difference between fb and fbconnect modules. fbconnect is included in just one module of the fb package.
what you're doing is like trying to comparing adobe to jedit, whereas the more appropriate comparison is jedit to dreamweaver... you fail to see the fecundity and size of the fb package compared to the relatively specialized fbconnect module.
d.o/p/fbconnect is just 1 module that's included in the much larger, comprehensive d.o/p/fb package that contains a very robust, well written and commented set of modules...
i'm trying to be diplomatic about this, but the reason there are an order of magnitude of fbconnect users over fb users is probably related to why the windows end user base is an order of magnitude larger than linux'
tell us how you create facebook canvas pages with d.o/p/fbconnect...
#4
I'm failing to "highlight this issue to those that care about it, and encourage the the discussion on what to do" ? That's my only goal here. The title is provocative for the sake of gaining attention. While many users (including myself initially) do misunderstand the differences of the modules, I actually do have a pretty firm grasp over what they do, and how they differ. If you need an example of my long standing relationship with this module, just check the revisions on the doc pages http://drupal.org/node/195035 :)
To clarify my point, when fbconnect module came out, dave and others suggested that they could just use the fb module and that a competing solution was not in the best interest of drupal. This is a problematic assertion though if the module isn't at a (non dev) release. Having not been closely involved in a while, I'm not sure what the difficulties are, but I have a couple guesses from my conversations with dave in the past.
1) Facebook is always changing things. For better or worse, facebook keeps changing the API, adding new things, etc. This is good for growth of the API, but can make maintaining such a module difficult.
2) FB is trying to do a lot of things, and has many moving pieces and modules. Many submodules may in fact be mature enough for production use (certainly sites ARE using it) but are being held up by more experimental modules
3) The API is steady and modules are ready for at least a beta, but no one wants to pull the trigger for some reason?
My suggestion is break the behemoth up.
The first thing might be a facebook API module to handle the basic facebook javascript embedding to make the facebook api available in a consistent way to any other modules that want to use it. Right now each facebook module has it's own solution for this, and my guess is that this module exists already in fb and is stable. People should not have to wait on such a long development cycle to be able to use this feature. If it were released as it's own module, immediately we could work to get the other modules to integrate it.
Second thing would be the usermapping. Again, each module is using it's own method to map drupal users to facebook users. There should be a more consistent method that all modules that need this can use. The facebook api group has a post related to this in an even more universal way... http://groups.drupal.org/node/26157
These are just suggestions, but I think focusing on these two areas would allow developers to create new modules that use the facebook api without having to either add new submodules to this this module or re-invent the wheel. The modules would be able to work together to solve problems, and implement new facebook features as they become available.
Thoughts?
#5
Thanks for the feedback, Frank. I'm on vacation at the moment. Will provide a more thoughtful response next week...
#6
Hello,
I like the idea of breaking up the subparts into modules of their own, just like many large projects are doing like Ubercart, Ecommerce, CCK etc. Drupal for Facebook could be the first app that would need to be installed, and then any submodule the user wants could be installed after.
They could be listed on the frontpage with links, just like for the Zen theme, with all its subthemes :)
#7
bump
#8
subscribing
#9
subscribing.