Posted by nodestroy on September 23, 2007 at 5:43pm
Hi,
here we discussed the development of the new buddylist verion: http://groups.drupal.org/node/5233
the current state:
- buddy_api module - API for buddy actions
- buddylist_ui module - User Interface for buddy_api, supporting oneway AND twoway buddymode
- buddy_api_shortestroute module - block to display the shortest route between two given users
- buddy_api_invite module - invite module integration
next steps?
please test and report bugs ;)
for more informations visit the project sites.
Comments
next steps
Great work!
I will test your modules in the next few days.
If the code will be stable, we could go further by optimizing the Shortest route module (eg. in large community sites with thousands of connections).
Are you plan to create a "Friends of friends" module (common friends of two, three...,n user)? Or a module wich lists profiles, that could be you budy (pick ups random budies from the user buddies to advise to the user, that maybe he/she know them).
Best regards,
Christopher Dely
Best regards,
Christopher Dely
thx!
yes, the shortest route algo has to be optimized, this is in work yet. I have spoken with Aron (SNA tool) at the drupalcon three days ago and he gave me some tipps.
when this four modules are stable, we can speak about further addons ;)
Something that would be nice
Something that would be nice is if it were possible to have a blocked-users listing... sort of the opposite of a buddylist. If there were such an API, it would be great if Buddylist could be set up to keep a blocked user from trying to join someone's buddy list, or keep them from adding the user who blocked them to their buddy list.
Currently, there is no blocked user functionality anywhere that I know of (I mean users blocking other users, not the admin "blocking" them from the whole site.)
I'm not sure whether a user blocking feature would or would not be a good thing to make part of Buddylist's API, although if it were part of it, then modules that allow/disallow access to private material could get all their info (show this/hide this/notify this person) from one place!
interesting idea, but...
...i think for such cases the "twoway" connection mode is an alternative solution. i don´t know any networking site which uses such a function. if i don't want that userX joins my buddylist, i do no accept his request.
it would be possible to implement such a function in the named relationship addon (which isnt existing yet). the thought is, that the admin can create a list of named relationships, and he defines if the relation should be one or twoway. here we could implement a relationship "blocked" (maybe as a default relationship).
the main target should be to keep these modules so small and efficient as possible, because of performance.
buddylist view bug?
Dear Nodestroy,
I installed the modules, and started testing the API.
It seems that buddy_api_buddylist view only displays the currently logged user, not his buddy list.
Do you have any idea?
The buddylist_ui module permissions are set.
The buddy_api_get_buddies function works well, only the view not works.
I used Michelle's tutorial to create the user profile using CCK and views.
http://shellmultimedia.com/node/274
Best regards,
Christopher Dely
Best regards,
Christopher Dely
Will the transition from Buddylist to Buddylist2.x be smooth?
I'm wondering if Buddylist 2.x module will smoothly replace the old Buddylist module on the sites that are already live, and which already have hundreds of users. In other words how is the table compatibility? Once I install this new buddylist module, will the existing users need to send requests to each other all over again??? That could upset a lot of people.
It would also be nice if the "Add to my Buddylist" links would appear more frequently and in more user-friendly places. Right now they appear at the bottom of the profile page only, wile they should appear at the top of the profile page.
It would also be nice to come up with the kind of listing of people that we see on Facebook whereby, "Add to my buddylist" link always appears next to the picture.
Migration is an issue.
This would be something to look at if the underlying data structures (database tables) are going to change from Buddylist to Buddlysit 2.x.
I guess the basic question would be - are the underlying structure of database changing? If so, I think I can put some effort into writing some migration SQL scripts - if the work has not yet been done.
-Vyoma
Oops!
Seems like it has been taken care of as can be seen in the project page:
Sorry for jumping the gun. :P
-Vyoma