Posted by fago on July 20, 2007 at 2:46pm
I'm glad to announce development of a buddylist 2.x module. Our team needs buddylist's functionality for a project, but decided that buddylist's (1.x) quality is too bad for use in our project and that the effort to fix it wouldn't be worth the trouble. So we'll build buddylist 2.x..
Buddylist 2.x design decisions:
- use views (for now with usernode..) for all buddy listing, so they are
extensible and customizable - use workflow-ng for all notifications, which provides e-mail notifications - or whatever you want (just write the appropriate action..)
- to simplify only the buddylist modus with "Confirmed buddies" will be
supported - no one-way buddy connections - only implement the basics in the module, other things should be built as add-ons.
So there will be no buddy-group functionality, or tracker integration (for
this views can be used nevertheless). - we have also planned to develop an extension, which shows the shortest
buddy connection to other people later - Probably there will be no need for changing the db-scheme. So
upgrading would be just a matter of replacing the module.
So in short the pros/cons of this design will be:
+ small, stable, performant module
+ good code reusing
- a lot of dependencies (views, usernode, worfklow-ng for notifications)
development will be done by nodestroy
Comments
One way buddies
There are many good reasons for one way buddies. Flickr has this concept: you add someone as a "contact" and you can then follow their pictures. Think also of fans and artists. If artists had to spend all day approving buddy connections, they'd never get any work done.
Uni-directional links are very important for many kinds of social graphs.
Dependency on workflow-ng seems a bit heavyweight. But, tying into things like (for example) privatemsg rather than email would be made much easier.
one way buddies are vital
in fact, our choice to use buddylist rather than roll our own was primarily based on the flexibility to have both one and two-way connections.
i don't understand how only providing 2-way buddies is a simplification - aren't 1-way buddies much easier to implement? it seems to me that most of the complexity is in the configuration options but i'm probably being naive.
from a user perspective, 1-way buddies are much simpler (which is why we chose to go in that direction as there's enough complexity in the rest of our site).
if you expect people to provide extra features through modular extensions, which piece is easier to add as a module?
Auto two way
If you ever had a look at the buddylist 1.0 code you'd understand why one might say just doing two-way only would be a simplification. The code is just nasty and polluted with constant checks for which "mode". My opinion is that both modes could be more easily supported in a complete rewrite of the code - whereas supporting it in the current code base sucks.
My idea was that all connections are two-way but you could provide an auto confirm functionality thus making it feel like a one way - that is the other user is not required to do anything like manually confirming. In this way all the code can be unified with just one check needed to "auto confirm" the request.
The down side of this without more effort is that the other person is now linked to these others and might not want them to show up. It seems like maybe this could be handled by tracking how the buddy connection was made (manual or automatic) or some other presentation scheme of a users buddylist.
Just an idea for discussion.
Dan DeGeest
Software Developer
Somewhere or Another
auto confirm wouldn't help
auto confirm wouldn't help much, as the connection would be placed for both directions.
However as there seems to be some interest in the one-way-connection, we thought a bit more about this all. So as we agree, this feature can't stay as it is. But to simplify the code, workflow-ng can help. As all messages will be handled with workflow-ng and/or actions users can customize the messages, so they fit also in the one-way system. So we keep the support for one-way messages, but the message customization is up to the user.
Anyway, the message customization needn't be hard work for users - As workflow-ng is capable of import/export, we could provide an importable message template for one-way-connection messages.
Hum, you're right... I
Hum, you're right... I forgot that's how it was implemented in the db.
Dan DeGeest
Software Developer
Somewhere or Another
Some interesting ideas
Some interesting ideas there, expecially the one about the "shortest buddy connection" (or "Degrees of Separation" as it is commonly known).
But please please don't remove the support for One-Way Contacts. It is the easiest way for users to regularly keep track of other user's postings. And what is the other person does not want to or doesn't have time to confirm each one as a friend. At least the One-way contact system should be kept as an option for Admin.
Buddy-group functionality is is also important for easily managing and remembering which "buddy" pertains to which topic.
Will this new module be a stand-alone module, or will it come as a replacement for the existing buddylist?
I'm pretty content with the existing buddylist as it is. It's only that it does not have FOAF and Degrees of Separation functionalities.
Fail early, don't waste hours getting there; clear labeling
So if I downloaded what you're proposing to build, installed, enabled, and set up the access controls, would registered users of my site actually get any new features?
If not, how many hours do you estimate it would take someone who is not a programmer to identify, install, and configure extra modules that might or might not actually add features, or try to get a View to work, to have their site's visitors have any visible new features? 1 hour? 5 hours?
Suggestion: modules that ship incomplete should have a "fail early" philosophy and clear warnings not to try to use incomplete modules unless they can pay someone (if they can find someone to hire). Otherwise, more and more site admins will waste hours downloading more and more modules and add ons, and struggling with Views, only to end up with a nonworking mess on their site that they have to spend more time cleaning up and deleting.
Install package
We thougt about an install package which comes with all required modules, so you only have to install this one install package and not all the modules. To place a view isn´t that difficult, and there will be a clear and detailed install-manual.
Updating the buddylist2 with other features (Buddy Groups,...) will also not be a very complex process, you just have to install one more module. The basic buddylist2 module will not implement more features than the buddylist, but it will be a better base to build more Add-Ons.
I'm curious
RE: "decided that buddylist's (1.x) quality is too bad for use in our project and that the effort to fix it wouldn't be worth the trouble" -- what were the precise issues that led to this decision, and did you get in touch with the module's maintainers?
While I'm always glad to see new development, and think that alternative approaches can often produce stronger code (ala aggregation work currently ongoing), this feels like a fork of the module --
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
fork vs. spoon
i think i have to agree that, if some of the primary features of v 1.x won't be preserved in 2.x, thus orphaning a significant part of the current userbase, that this should be considered a fork - or a new module - and renamed somehow to make that clear.
EOL for Buddylist 1.0
As the current (not-so-highly-motivated) co-maintainer of buddylist, I applaud this effort. In fact, I had decided that I would not port the current buddylist module to Drupal 6, but would rather use the opportunity for a rewrite. Fago's proposals sound similar to what I had in mind. I was planning on targeting the Drupal 6 actions module and I don't know whether the decision to go with workflow-ng affects this or not. This would be my main concern with the proposal.
Here is the short version of the vision I was going to strive for:
My ideas and fago's are similar. Fago's modules are usually well maintained and well thought out. I can only see this development as a good thing.
With that in mind, then...
Hello, Robert,
Thanks for the clarification -- that changes the terrain a bit --
And with that in mind:
+1 to views -- but why limit just one approach to managing users? While core profile is dying a slow death, there are still some solutions with it that work pretty well, and requiring usernode as a pre-req to buddylist will have some users looking elsewhere for buddylist solutions (and/or, potentially increase the rate of adoption of usernode).
Why not support both? With Actions in core, the terrain has changed (somewhat) and I would say the stakes are a little higher -- given that you want the core of the module to be lightweight (and using Robert's suggestion of "An api for managing the relationships that makes no assumptions about workflow whatsoever") it doesn't make sense to limit the potential uses of this module by restricting it to one of two workflow solutions.
This has been discussed -- one way buddies (particularly when paired with Robert's suggestion of named relationships) are a Good Thing
Yes - although I would recommend the "Buddylist Groups" helper module as both an example and a real nice feature.
This is sweet - this would also be incredibly cool when combined with Location API -- visualize closest friends w/in a certain distance -- but that's for way down the road.
Cool - an upgrade path is always helpful, particularly considering what Robert is saying about EOL for buddylist.
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
1) Views requires nodes,
1) Views requires nodes, right - so we need usernode, bio, et al. It seems like buddylist would have to provide views support that includes some abstraction for what type of user node is used?
2) actions! yes, you can use the module in D5 and core in D6 - seems like an obvious choice
3) Support both but in a way so the code isn't polluted with if/else/switches - lets get the code away from littering the code with if (variable_get("confirm"), FALSE)... stuff
4) Agree - also make the api such that its easy to add things like patches I've made in the past such as including a short message with the invite that don't require patching the module.
5) Sweet - I did some stuff with a flash based user spring graph - this would be cool to hook up to this or some other graphical network viewer.
6) Maybe. On feature I'd like to see added is a buddylist logger ( I did this for a past project by hacking the 1.x module) that records all the invitation activity - invites, declines, cancels, removes, etc.
7) One of the biggest pains in 1.x is modifying all the text messages - lets get those out of buddy list and into actions and/or some other easy way to alter them. The new buddy list module IMO shouldn't have any drupal_set_message calls. In addition make it easy to change the language of the core concepts - ie. we want to call them "friend" not "buddy". The 1.x handlling of this wasn't great since you could change those terms and end up with sentences later that were nonsense. Also, add more things that can be change - ie. we want to call them "invitations" not "requests" or "invited" not "requested"
8) Better theme support!!!
9) I'm willing to help with development - contact me if you want help.
Dan DeGeest
Software Developer
Somewhere or Another
ad 1) views requires nodes,
ad 1)
views requires nodes, yeah. that's why usernode is needed. Bio or nodeprofile are no alternatives, as there needs to a node for every user, even if there is no profile. But anyway, if people want to go with bio or else they still can edit the views.
ad 2)
actions for d5 wouldn't help much, because we would have to reinvent the whole action execution system. That's for what workflow-ng is used. In d6 we can support them.
ad 7) You will be able to edit all text messages, as all messages are generated through workflow-ng actions. But probably we still need the replacement system for things like page titles, menu item titles and so.
ad 8)
yeah!
ad 9)
That would be great! I think we can flush out a first prototype soon and put it into cvs for collaborative development.
1) bio does enforce a 1 to 1
1) bio does enforce a 1 to 1 user/bio node relationship. But yes, the views could be cloned and tweaked. I understand you are favoring your own modules which I'd do the same since I'd be most familiar with those.
2) so whats the final list of dependencies per the current design ideas?
views
usernode
workflow-ng
token
it seems that the base module could still be designed that had no dependencies and had enough custom API hooks and theme support allow hooking up actions, workflow-ng, views, token, etc.?
Dan DeGeest
Software Developer
Somewhere or Another
ad 1) That's not the main
ad 1)
That's not the main cause, as a said: there isn't necessarily a bio node for every user, so you can't use it for your views.
ad 2)
yes. workflow-ng and token are only required if you want notification/messages/mails.. But without buddylist would not seem complete..
Views and so usernode will be required as any user listing is done with it. This results in much more flexibility, like easily added table columns...
Views 2.0 won't require nodes
http://www.angrydonuts.com/views_2_high_level_design
Not that this should necessarily affect the decision-making here, but it's cool!
~ ben melançon
member, Agaric Design Collective
http://AgaricDesign.com - "Open Source Web Development"
benjamin, agaric
great
great to see that we have the same visions.
@d6: workflow-ng and d6 actions are quite similar. Workflow-ng allows us to go with the actions concept even with d5. For buddylist 6.x we can support both, d6 actions and workflow-ng. So I see no problem here.
@api & views: agreed
@named relationships: This is a nice feature, but it might not be needed for all the sites using buddylist. So I think best it would be to implement buddylist with features like this in mind, so that extensions can implement them.
6 & 7
ad 6) We planed to implement a logging system for all buddylist actions.
ad 7) Through the connection with workflow ng all the mail texts will be unneeded.
Token support
the text problem buddy/contact/friend etc need token module support. This should be an absolute first-level goal of any rewrite.
I am a big fan of the token
I am a big fan of the token module, but I can't see how it could help us with this, as the token module does also nothing more than textual replacements.
But could you explain your idea a bit more detailed? Sounds interesting.
Taking notes from the Points module
Sorry to come in so late in the conversation...
Let's not forget the core reason this module exists is to define relations between users much like categories do for nodes. As such I think the 2.0 direction should be focus on that core and kick out everything to other modules to handle.
Robert's idea of having Named relationships is bang on the #1 reason to consider this module.
In the end I'm suggesting we follow a philosophy like the VoteAPI, Points etc modules.
Thoughts?
Cheers.
Yes
Including NO depending on usernode etc. We should be able to have user connections by enabling nothing more than buddylist + user module. Sorry, but there are many cases where usernode is overkill, but you still definitely want buddylist connections. Make a new module if you want to fork it to work ONLY with users-as-nodes.
Yes Yes.
I fully agree.
Side note: I find viewing users as nodes, philosophically speaking a little disturbing. ;-)
Cheers.
buddy api
We could split the module up into two modules, an API module and one providing the interface. The API would have no dependencies, while the UI module would depend on views and so usernode.
Anyway, this would result in two modules instead of one. Perhaps then people would grumble about so much modules they need to install...
So what's preferred here?
If I understand correctly in
If I understand correctly in Views 2 there is a plan that
Wouldn't that remove the dependency from the UserNode?
btw, IMO installing 2 modules (API+UI) isn't a big issue.
I think usernode has its
I think usernode has its place, so does bio, and views is a great module so I'm not grumbling but only interested in the best, most flexible module. That said, I really like the idea of a core module that tracks the buddy relationships and has enough hooks and theme support to let me choose how to present and work with that data.
I also think providing a default UI solution is fine and it can use whatever modules you think are best.
So I think splitting up the modules is a good idea. My only suggestion is that the default UI module would be built only on core drupal features like themed lists/tables and custom theme functions, and the basic user account. A usernode, views add-on could be completely abstracted out.
Dan DeGeest
Software Developer
Somewhere or Another
yes. usernode is only
yes. usernode is only needed, because views needs nodes.
+1 for separating buddy
I have two reasons.
So while I have no aversion to views and usernode, I'd hate to carry baggage when all I want is relations.
Cheers.
Hmmm...
Right now, Buddylist, regardless of what kinds of horrors are happening 'under the hood', is an easy "drop-in" solution for a contact manager. You enable it, click a few things on the settings page to make it work the way you want for your site, and users can start adding buddies.
The re-write sounds like it complicates things by a LARGE degree, and places all kinds of dependencies on other contrib modules which may or may not be updated during each iteration of Drupal. And while you can help users along, for example by bundling in default views to replicate what's currently in buddylist module so now extra setup is required, I'm not sure this is fundamentally a good direction for this module...
We use buddylist 1.x on the Sony sites, and are using core profile module, not user nodes? Why? Because profile module, regardless of its problems, is guaranteed to be updated between Drupal 5 and Drupal 6 because it's part of core. I'm not too worried about Views, since everyone uses that on their sites, so someone will pay to get it ported. But Usernodes and Workflow-NG are highly specialized, and only used on a few sites comparatively. Not to mention an extra X nodes to match X users on the site. Sites like MTV UK are dealing with upwards of 500,000 users. That bloats the database to a non-trivial degree.
People who use Buddylist module are now going be held hostage to the release schedules of three different modules when they want to update to the next version of core. This seems like a user unfriendly move, regardless of what kind of additional power it brings.
That having been said...
...by all means, build in hooks or whatever is needed to get buddylist to work with these optional "power user" features. But I think requiring them is going to leave too many people behind and cause someone to create a fork of Buddylist.
first off, the extra setup
first off, the extra setup of install a few modules is done in a few minutes, so this shouldn't be the problem.
It seems you got usernode wrong, it's not intended to replace core profiles. It's no profile solution, the main reason I wrote it is to be able to list users with views. With views 6.x supporting users, buddylist 6.x wouldn't need usernode any more. So one problem less.
So as you aren't worrying about views being ported, what's left? - workflow-ng, which is only required for notifications.
First off, I know it'll be ported, as I'll do. Then with buddylist support for drupal 6 actions, one could use them instead.
Anyway,
what's about making an extra API module or include for different UIs? Anybody interested in this?
A port of the 1.x UI to this API shouldn't be hard..
Apart from that, there is of course still the possibility to stay with buddylist 5.x-1.x and wait for buddylist 6.x to upgrade..
looks good
as you say, i think we are ok with the proposed dependencies. actions is in core, and views2 will list users. i see no issues here. please do maintain one way relationships.
IMO a UI module separate from the API module makes sense. This is how Views works, among others.
thanks fago.
+1
I agree with Moshe's comments.
In addition, I wanted to say thanks to fago for all the work on the various modules and also for being very responsive to the community's needs in terms of maintaining 1-way relationships. A need was expressed for it and fago did an excellent job of coming up with proposed solutions.
Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing
Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing
Agreed; API + GUI works
Agreed! This is very positive.
Also, the solution proposed below of having buddylist split into an API and various GUIs sounds like a good one to me; I've successfully used the Voting API with a number of modules that provide, in essence, "canned views." I'm a little wary of things that interact with Usernode and require you to modify usernode, because I haven't been able to get custom profiles working (note: I tried this on 4.7). A GUI + API model splits the difference nicely between people who want a highly customized solution and people who just want to install something that works. I leave it to others to determine whether bringing in additional modules like workflow and token creates additional complexity.
Just say no to unecessary dependencies
I have to say that I'm concerned about the discussion of massive dependencies. Modules like usernode and workflow-ng are not trivial and requiring that users drop them in for functionality as simple as users connecting to other users.
A shared underlying API that does nothing but manage typed connections between users, and exposes hooks for other modules to tie into, should require no dependencies at all.
I don't think it is really
I don't think it is really massive dependencies:
* Usernode - just until Views 2 is out
* Views - don't leave home without it ;)
* Workflow-ng, (+token) IMO this module is the next CCK/ Views. From a point of view of a non-programmer I'm able/ going to be able (hint hint fago) to control things that otherwise I must use code in a very simple manner.
If we split it up, the API
If we split it up, the API module would have no dependencies.
But imo separating code into modules/APIs is really important - this allows use to reuse code much better. That's all.
So a lot of people are requesting better theming possibilities, because they want to customize the buddy listings - which was never possible and so they hacked the module.
The ideal, ready and well known solution for this is views.. So why shouldn't we use it?
Of course, it's not great to have to install more modules. But should we go and recreate existing functionality only to have less dependencies?
Drupal is a giant Lego. It
Drupal is a giant Lego. It is impossible not to create dependencies. a proper packaged installation will probably solve this issue.
I strongly agree with Webchick
I have mixed feelings. As a Drupal consultant - the more complex the configuration is - the more my work is valuable.
But, I work with non-profits and try very hard to let them do as much as they can. A very common situation I find -- is a user who has configured all but one setting. They bang their head against a wall because nothing works until everything is setup correctly. Most often they give up just when they are getting close.
Remember, a new user is hunting and pecking to figure things out. So, each additional "requirement" exponentially increases the chances of NOT getting something to work.
I have not followed this thread closely so I may be off topic here. But, it seems to me the goal is to have both: An out of the box module that when installed (already a non-trivial task for many users) gives immediate functionality and, as many hooks (especially theming hooks) in the module as possible. I have already hacked the heck out of the module for one client - just to get the theming right.
Are these two ideas so incompatible?
No, your not off topic -
No, your not off topic - that's what I'm recommending. I'm also doing drupal for paying customers and I had to also hack the crap out of buddylist to get it to look and behave right and then was left with code I couldn't keep in sync with the head development.
I'm starting a new project that relies heavily on buddylist and starting over with the 1.0 release and doing a better patch management but going to face the same issues when it comes time to alter text messages and theme the displays.
My suggestion is
1) buddylist.module handles the buddy relationships (one way, two-way) and all UI to facilitate that can be changed with hooks and/or theming - any combination of both. No dependencies.
2) if I want views I can add bio or user node and build views on those but buddylist never needs to know about that.
3) I can call buddylist apis to get relationship info, the "number of steps to user A" (love this idea), FOAF, etc.
Dan DeGeest
Software Developer
Somewhere or Another
This sounds great
Just for the record... the three area where I needed more functionality were:
1) Changing how each buddy looked (my client wanted avatars and other profile field data displayed).
2) Changing the sort order of buddies (the site is driven by donations and big donors get listed first in every view).
3) Auto subscribing new users to a few selected users - this helped welcome new users and demonstrated the available functionality.
From this - I would love to see these hooks:
1) More theming hooks (to change from a table based layout or to change how individual buddies look)
2) Hooks for returning lists of buddies
Buddylist Issue Queue
Robert committed a patch that gives you the ability to theme your buddylist without hacking the module -- http://drupal.org/node/152240 -- please add issues to the buddylist issue queue if there are other theming hooks that you want.
Marc
http://www.funnymonkey.com
Tools for Teachers
That theme hook was a good
That theme hook was a good addition but doesn't cover everything. For example, theming the display used at ?q=buddylist - that doesn't not use this theme function. I've created a patch for this
http://drupal.org/node/163104
There is a another patch that if committed would be a start to moving out the drupal_set_message stuff to make that extensible.
http://drupal.org/node/121054
Dan DeGeest
Software Developer
Somewhere or Another
A vote in favor of dependencies
Modular code is a good thing. The more we look at how our modules can interact, the easier it is to build new functionality without hacking.
(For instance, if a relationships API existed yet I'd recommend this module use it.)
I think for normal users willing to give up a little security for convenience, and/or if security issues can be addressed, allowing modules to download and install other modules would be the best of both worlds...
benjamin, agaric
members module
Instead of using views + usernode, I'm very willing to put further work in the members module to profile it's user listings.
This is a an interesting
This is a an interesting idea since members is basically views for the user table. Perhaps, buddylist needs no built in UI at all and your options for viewing your network is a host of 3rd party options such as members, views + bio/usernode/etc., flash based graphs, custom, others....
Buddylist need only expose the proper API.
Dan DeGeest
Software Developer
Somewhere or Another
SNA Project
http://drupal.org/project/sna
Named Relationships and more
Hi,
So I was asked to create a Named Relationships module for a company using Drupal for its main sight. Requirements for it were to have named relationships, default adds, invite support and hierarchical relationships (eg. manager is also coworker). I tried to get CVS rights to put the module back out to the community and I got routed here.
So I figured I'd show you all what I had and let you decide if I was worthy of helpin' out.
I hacked it together in a couple days and managed to implement the following:
2 way (only) named relationships
default relationships (a user automatically gets related to a chosen user on signup)
invite support
Here's the code: http://squishtech.com/drupal/modules/user_relationships.zip
Please let me know what I might be able to do to help out.
A Drupal 6.x-targeted
A Drupal 6.x-targeted rewrite? Very good. I will wait to see what benefits/un-benefits this one has.
1) Please keep one-way relationships
2) Eventually, I would hope (I may fork/patch this in myself later) that support for adding non-members to a buddylist (think XFN) could be done. Then, if they log in (think Drupal 6.x OpenID support) their account is associated with the friend entry
any update
is there any progress on this rewrite? please keep us informed, and share as much as possible as early as possible. i have some social network projects itching to launch :)
Never heard back
I haven't heard anything new about this. So I went ahead and rolled my own.
I called it User Relationships.
http://drupal.org/project/user_relationships
that's bad :( It's important
that's bad :(
It's important to use the same APIs, so that things that build upon it work together.
the buddy api already supports named relationships - so it would be great if you could port your work to the same API? If the API is missing features, you could create a patch for it...
Anyway most of your features would be doable with buddylist 2 and some actions.. except of the "User Relationship Implications" - I'm not sure what this is about sry.
Needed something
I just needed to get something out the door.
If the development of the new buddylist module is moving along (and from nodestroy's recent post it looks like it is) then I'd be more than happy to use it.
I'll take a look and start porting over.
The implications plugin automatically creates a relationship based on a requested relationship. The example that I was trying to use in the documentation was that of a Manager also being a Coworker. So if I set myself as a Manager of another user, I should automatically have a "Coworker" relationship set between us as well.
dev version
the first version is online
http://drupal.org/project/buddy_api
first stable version will be come within the next few days
Node relativity will perhaps give you what you want quicker
Node relativity module seems to provide some of the things you are trying to accomplish in more generic way. After all buddylist is a relationship with two node in a directed way. I have not tried all features yet but seems to provide features for node traversal etc.
http://drupal.org/project/relativity
I'm disappointed with the
I'm disappointed with the usernode dependency. I tried usernode and honestly, I like the core profile module better for now, mainly because of the linked field values and for the streamlined integration with the registration. I found that I could achieve the customization that I wanted just by re-writing the phptemplate for user_profile, and still keep the advantages of the profile module.
I understand the desire to use views... but... I won't be using buddylist2 unless there's a node based profile in a future version of drupal which it works with.
I also don't like the "it's easier to code" justification for getting rid of (or otherwise garbling or whatever it is you're doing) with the one way buddyship. If it's useful to the users, it's worth finding a good way to do it, IMHO.
Sorry.
usernode...
...is no profile solution, it is just an empty node for each user, so that we can create a connection between the node table and the user table (also see here: http://drupal.org/project/usernode). In Views2 you can build views over all tables (no node table relation is needed), so the dependency to usernode will be gone. You can use any profile solution you want.
The API is ready for one way relations ;)
Upgrade Path, Continuity and Dependencies
Clear upgrade path and continuity
One of the things most of us have come to appreciate and value about Drupal development is the continuity of modules, (sometimes not so easy) upgrade paths and collaborative efforts around modules serving a significant number of users.
I'm all for a "small, stable performant module", but we should not leave any previous functionality behind or exclude features already being used by existing users.
No problem with leaving "buddy-group functionality, or tracker integration", or one-way buddies outside the basic buddylist 2.x version, but the additional "extension" modules to deliver these features should be implemented at the same time in order to maintain credibility in our developers community and the stability of Drupal as a trustworthy and stable platform.
On the other hand, it's not just a problem of excluding those features, but of being able to explain our users and community members that those features are no longer available...
I'm pretty sure many of us will be more than happy to pitch-in and/or collaborate with the development of these features.
Again, I can not overstress the importance of not leaving existing features out when performing an upgrade.
The advantage of API's and harmless module dependencies
The recent increase in the development of API's and shared components by contributed modules, particularly since Drupal 5 and clearly after Drupal 6 arrives, is a very positive trend that allows leveraging the work of others and simplifying development, configuration, implementation and customization, although it may seem as the opposite on a first glance.
Yes, it was awkward for me, when I recently upgraded a simple and basic module as pathauto to discover it now requires token to be activated, or that privatemsg now depends on subscriptions.
But if dependencies are clearly identified (as is clearly visible at the admin/build/modules screen), clearly documented and clear documentation for installation and customization are provided, this should not bring any kind of complication (eg. 1. download and install the A module and the modules it depends on - X, Y and Z -. 2. Go to admin/by-module and customize each module and user access to its future. 3. Congratulations and welcome to the happy world of module A users).
The thing is that using API's and leveraging the features and functionality of other modules, allows contributed module developers to focus on the specific features through which their modules add value to a Drupal installation. If they don't have to worry about coding functions for sending or receiving messages or passing variables around, they will have more time to make the module stronger and better.
This has always been part of the Drupal development experience through the Drupal API and now is happily growing through additional API's (eg. Voting API, geonames API, date API, event API, and so many other API's that have given us great modules sharing a common set of features, functions and features).
The disadvantages of Using Node Profile
As it has been mentioned by others above, dependency on modules that replace the functionality of modules assumed standard and used by several other modules such as the popular Profile module (required by AdSense, Birthdays, i18n - profile, Profile Privacy, Site User List) might actually complicate things for community developers, forcing them to replicate or recode relationships and features provided by those modes.
And let's not forget that Node Profile itself depends on Node Family and Subform Element (for Drupal 5.x).
The Advantages of Using Node Profile
Sure that the availability of Node Profile to use Views can simplify replicating some of those features and facilitate the addition of new community features.
On the other hand, using node profile is much more efficient than "just (...) re-writing the phptemplate for user_profile", particularly for those of us using several themes. Anything that keeps me from patching or modifying code components of modules and core is highly welcome, at least by me and anyone maintaining more than one site and more than one theme.
To Sum It Up
Sorry for the long post, but this module is critical for the community work and engagement many of us count on to build stronger relationships and promote collaborative efforts.
con paciencia y calma,
sube un burro a una palma.
con paciencia y calma,
sube un burro a una palma.
Is this dead? Haven't heard
Is this dead? Haven't heard a thing about this since october.
http://joshuaellinger.com
No, not dead. Check out the
No, not dead. Check out the Buddylist2 project.
also take a look at
also take a look at http://drupal.org/node/203335 for up2date details
allready done
Hi,
now we have a dev version package for testing
http://drupal.org/project/buddylist2
it would be great, to get some feedback about this
regards,
nodestroy
Which buddylist module?
It looks like both buddylist modules for Drupal 5 are either "beta" or "dev".
Which buddylist module should be used on a new Drupal 5 site? Is there going to be a way to upgrade the buddylist modules to whatever new buddylist module becomes the standard one?
As far as I know there will
As far as I know there will be only one buddylist module for 6.x. Hope this port can be done soon.
I use Buddylist2 for my 5.x sites. I think it's ready for a full release if this annoying bug wouldn't exist. Seems to be a hard one. But overriding buddylist/requests with a customizezd view is solving the problem.