Closed (fixed)
Project:
FriendFeed
Version:
6.x-1.x-dev
Component:
Miscellaneous
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
21 Sep 2009 at 20:15 UTC
Updated:
5 Oct 2009 at 21:30 UTC
You could've just created an issue in the FriendFeed issue queue. I would've given you commit rights, and then we could've opened up the DRUPAL-6--2 branch.
I suggest we close this project, and move everything over to the FriendFeed DRUPAL-6--2 branch. We don't want Druplicate Modules.
Comments
Comment #1
robloachThe original FriendFeed module is extremely outdated, and that's why this 2.x API is a must need. Let's just have one Drupal module please ;-) . I've given you commit access.
Comment #2
mark trappI tried to explain the rationale behind this module on the project page, and I guess I failed. Let me try to clarify:
1. I don't see this as a duplicate module of FriendFeed: v1 of the API isn't superseded by v2; they're two different APIs and both are supported by FriendFeed.
2. In addition to concurrent support of the APIs, the design goal of this project isn't to replicate the functionality of the FriendFeed module (that is, to add all the end user features like the activity stream or publishing options to nodes), but to provide the FriendFeed API v2 to other module developers.
For these two reasons, it seems like it'd be remiss to create a 2.x release of FriendFeed given what that tends to imply (that you should upgrade because version 2 is better). If you want the v1 API or have your FriendFeed activity on your Drupal, use FriendFeed. If you want the v2 API so you can build modules based off of the v2 API, use this module.
I'm open to finding a way that allows the two different APIs to be maintained concurrently rather than v2 superseding v1: keeping the projects separate seemed like the best way to deal with any API version mismatching that may occur by another module that uses one version of the the API versus another. For example, I want to prevent the scenario where I can't develop a FriendFeed API v1 module because I have to assume, since 2.x is the newest version, that when I invoke the friendfeed module or depend on it, it's using FriendFeed API v2.
What do you think?
Comment #3
mark trappThinking about it a little more, one way to approach this is to spin the API portion of the module off into its own module. So, FriendFeed as it is right now is broken into two modules, friendfeed 1.x and friendfeed_api 1.x. This module here is released as friendfeed_api 2.x, and some enterprising individual is free to replicate the functionality of friendfeed 1.x using friendfeed_api 2.x and release it as friendfeed 2.x. This way, third-party developers can specify that they need friendfeed_api 1.x or 2.x.
The major problem I see with this is that I can't run two modules that depend on different versions of the API: either my site is v2 enabled or it's v1 enabled, which is not ideal.
Comment #4
mark trappI just talked to Benjamin Golub on FriendFeed, and they are saying all new projects *should* be written in v2, so maintaining concurrent projects should not be necessary (and thus obviates this module). I still have reservations about providing a module that does more than just the API, and would like to see that split up (even if it's in the same project), but I'll create a new issue for that in the FriendFeed issue tracker.