I've been trying to track the discussions at the workgroup and I've looked at the project page for buddylist as well as for buddyapi - and I'm very unclear on whether buddyapi will just be a fork and this will be maintained separately, or what...

Honestly the start that buddyapi is off to is not very impressive. There have been no recent commits to it, the issue queue is dead and the whole idea seems to be a bit of a mish-mash at the moment. Unless something changes with that situation I really hope that buddylist stays intact as is now and is upgraded for Drupal 6.

Regards,
Caleb

Comments

dldege’s picture

Good question.

I'm currently continuing to work on the Drupal 5 version to make it as customizable and useful as possible given the current code base. I'm targeting changes the make what is there more usable not entirely new features. You can look at the recent commits from me to see the types of things I'm doing. I have no plans at the moment to port it to Drupal 6 as I figured buddy API would supplant buddylist but I'm not involved with the development of that or privy to discussions about. I'm also not the official maintainer of buddylist so I'm just fixing and enhancing as much as I can.

Personally, having worked in this code for awhile now I think its not a great idea to move it to 6. Even though the 5.0 version "works" the code is not the best organized nor easy to maintain. It suffered from some short sighted design decisions and feature creep. I have not reviewed buddy api but if its not up to task I suggest a rewrite of buddylist for Drupal 6.

Caleb G2’s picture

Ah. Your answer is exactly one of the reasons I asked about this - I feared this might be the case...it sounds like buddylist functionality is in danger of falling through the cracks entirely for Drupal 6 for due to miscommunication.

Let me state clearly for anyone who stumbles upon this -- it's one person's opinion (mine), that buddyapi is not nearly ready, nor does it seem to be preparing itself, to supplant the current module. Whatever limitations buddylist.module has right now, at least it works...

robertdouglass’s picture

Caleb G: whoever volunteers to do the buddylist port to D6 will be facing a great opportunity to clean up the existing code!

I've not reviewed buddy api yet (I assume we're talking about what is currently being comitted by fago and nodestroy in the DRUPAL-5--2 branch of buddylist?). I know that the personal temptation to rewrite buddylist from scratch and delegate things to other systems (actions/views/workflow/privatemsg etc) is strong.

nodestroy’s picture

Hi,

What I thought was: why not use powerful modules like views and workflow ng for the new buddylist version. The main reason for the split up into an api and ui was, that there now can be different kinds of user interfaces. The api provides the same features like the "old" buddylist version, but your right...its not stable right now. I am working on it, and I think it will be ready soon.

@drupal 6 port:
I will port buddy api and buddy ui to d6....there will be many advantages in compare with the d5 version (e.g. views support for all tables...no usernode module required...and so on).

my thought:
1) work for a stable version for d5
2) wait till the required modules are ported to d6
3) port buddy_api and buddy_ui to d6

Caleb G2’s picture

Hi all,

Glad that conversation has been stimulated! Also, nodestroy - your concepts themselves sound decent and in the spirit of OO principles - so that's great. My main concern was just that many people have been assuming that 'someone else' was already taking care of things. So if more people are now aware that is not the necessarily the case, and that there is more work to be done, then mission accomplished for this issue. :-)

dldege’s picture

I'd be interested in porting buddylist to D6 but not ready to officially volunteer yet and not up to speed on D6 yet to do it. Before any final decision I'd like to understand the relationship of buddylist and buddy api going forward. My idea is buddylist (for the masses, easy install and admin) and buddy api (for the super geeks, pro devs, etc.). A port to D6 could allow the module to be greatly simplified, cleaned up, and at least avoid the pitfalls of the first module in particular with better theme support, more API available, better translation support, more hooks and more integration with other modules.

ZrO-1’s picture

I'm posting here mostly so I can keep track of this thread as it's a very interesting conversation.

I have a few thoughts I'd like to share about the future of buddylist, buddylist2, (and user_relationships). I think that there is room for all 3 of these modules to coexist without too much confusion. At most, maybe someone should write a page/story about what module is best-suited to what user-interaction need - maybe once buddylist2 and/or user_relationships are out of dev.

Generally I think it all boils down to the amount of social networking on a given site.
For example:
If a drupal site is aiming for a "facebook" or "myspace" level of social networking - where the users and their inter-relationships are the focus of the site - then a module like buddylist2 or user_relationships would be a better fit.
If a drupal site is aiming for a "digg" level of social networking - where you'd want to keep tabs on what your friends/buddies are doing on the site, but not much else - then a module like buddylist is more appropriate.

I'm pretty new to drupal, so I don't have much of a background to go by, but it seems like drupal users have gotten used to the idea that there was only one module that added inter-user social network building. Now that there are some options popping up, people are unsure which module would be most appropriate for their site's user's needs. I feel that multiple modules for social networking is a good thing, just so long as there is an obvious differentiation between the modules.

Just my 2 cents.

nodestroy’s picture

@dldege:

we have put all the buddylist 2 stuff into the buddylist durpal_5--2 branch, so that we can easy build a "ready to use" package. in d6 it would be quite easy to install buddylist2 with the buddylist_ui module...so that it looks similar (almost equal) to buddylist.

nearly each site will have the views module enabled. the notification stuff could also be done by d6 actions... so the dependencies are quite not very "deep going".

buddylist and buddylist2 are doing the same but buddylist 2 can do much more than the old version. i don´t see any advantage to work on both versions. do you?

regards,
nodestroy

dldege’s picture

@nodedestroy

Thanks for the update. No, I don't see the need to port buddylist to D6 if buddylist 2 is going to offer the same functionality. I'm looking forward to having some time to review the work going on in the 5--2 branch and can hopefully lend a hand when things lighten up for me.

dldege’s picture

Status: Active » Fixed
Muslim guy’s picture

Privatemsg is integrated with buddylist

I lok forward to buddylist also tied to `nodeaccess'

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.