Hi,

Since this is a very important topic, and there is considerable (and sad) overlap in the Drupal world about this, please add here your comments to this module!

NOTE: comments of people who have SEEN the source code of FriendList _and_ other modules as well will be taken _much_ more seriously by me.
One of the very few things that makes me really angry is bad source code. Another one is people defending bad source code.

I am not that scary though. I just act it ;-D

Merc.

Comments

michelle’s picture

michelle
she/her
Primary language English
Location Wisconsin, USA
commented

Ok, here's my question, and it may seem harsh but it's a serious one. How committed are you to this? As you note on your project page, there is already a serious splintering of effort in this area. UR got pretty far and now suddenly it seems abandoned. Anyone betting on that horse is now at a dead end unless it gets picked up again. Friends/buddies/whatever is a serious issue on a SN site. If we go with your module, we need to know you're going to stay the course.

Another question: Do you intend to offer any conversion from the other modules?

And a curiosity: Is this from scratch or a fork of one of the others?

I was not happy to see UR die because I haven't heard good things about B2. And now here we are with yet another. I'm still hanging on to buddylist 1 at the moment but moving to Drupal 6 gets closer all the time. I need to make a choice of what module I'm going to get behind on my own sites, what I reccommend on SocNet, and what I integrate with in my modules.

Thanks,

Michelle

mercmobily’s picture

mercmobily commented

Hi,

I realise that you are concerned. However, I don't see splintering at all. I wrote Friendlist because in September 2008 there was NO way, in Drupal, to 1) Add friends 2) Have a reasonable API to manage them 3) Run good code.
I was tackling the problem of Drupal being an OpenSocial container. And then I realised that Drupal didn't have a way to define _friends_.
I didn't like UR's code. I might be biased. However, I wouldn't pick up the code.
So, how committed am I?

* I am not new here. I am the maintainer of http://www.drupal.org/drigg , http://www.drupal.org/user_karma and http://www.drupal.org/extra_voting_forms . I have been for nearly a year. Have a look at the issue list of those modules. You will notice that there are *some* feature requests, and no bug reports.

* I am an immensely prolific coder. I wrote the 1657 lines of code of friendlist in 54 hours, 8 of which I spent sleeping, 2 eating and 2 of them washing/etc. That includes designing the API and testing. I did chair Yoga as I programmed. I was on a mission: I wasn't gonna get up until I finished. And I did. Drigg was developed in a very similar fashion

* I did all of the development on an EeePC in telnet on a slow connection with a remote server. I did this while on holiday in sunny Italy, with the beach (and friends) at walking distance. Each day was sunny and beautiful. Each day, I didn't move from here. As I said, I was on a mission (which is now accomplished).

* It doesn't actually *matter* how committed I am. The API is there. It's good. It's crystal clear, well documented, and it makes so much sense that you will wonder why it didn't exist before. The Web UI is basic but it's all there. If I stopped developing FriendList tomorrow, it would still be an amazing asset for Drupal and for you guys.

* And yes, I am "that" Tony Mobily from Free Software Magazine. Not suree if it helps...

I am afraid I can't offer conversion from the other modules. That will need to be user-submitted. My mission here is to concentrate on Drupal having a good Friend API, and ensure that it will.

About this:

"And a curiosity: Is this from scratch or a fork of one of the others?"

Now, *I* don't mean to be harsh. However, in order for me to take your posts _really_ seriously, I _really_ need you to look at friendlist's code.

Then we'll talk for real.

I am not normally this harsh. Sleep deprivation is one if the issues here (it's 10:00PM and I am about to go to sleep for the first time). But it's not the only reason.

The reason why *I* am harsh, is because I am appalled by the lack of predetermined, "certified" APIs in Drupal.
Eaton's Voting API made it. But UserPoints are still painfully hanging around -- now INTERFACiNG with VotingAPI and causing me a great deal of trouble. There is no "friend's API". My own karma module, which is now nearly ported to Drupal 6, is fantastic, it has a plugin architecture, has been supported for nearly a year, and very few people even know it exists (although a direct link from drumm's "karma" module helped).

I am writing an article entitled "The sorry state of Drupal development", where I highlight the fact that it's OK if a third party crappy module is... well, crappy. However, when some crucial modules are missing, and instead of them we get a bunch of crappy third party hacks which don't even manage to compete with each other, then we have a problem. (again, Eaton's APi is fantastic)

I sacrificed my own time, my holiday, and myself. But this shouldn't have been necessary.

in my opinion, Drupal needs a set of "official" modules that are at least supervised by "trusted" developers and that are released *together* the day a new version of Drupal comes out. That would include:

* Voting API (there)
* Friends API (there now, I hope)
* Karma API (maybe mine?)
* A voting form (definitely NOT extra_voting_form, but a _nice_ one; yes, something better than 5star)
* Mini-views (a simplified version, not sure it exists)
* CCK
* ... and others

What a mouthful. Time to rest.

Merc.

P.S.
Don't forget to read the code...

mercmobily’s picture

mercmobily commented

Hi Michelle,

I just went to your user's page and looked at your list of patches and posts.
I need to take something back:

-----------------------------------------------
Now, *I* don't mean to be harsh. However, in order for me to take your posts _really_ seriously, I _really_ need you to look at friendlist's code.

Then we'll talk for real.
---------------------------------------------

I humbly take this statement back, take my hat off, and tell you that I will take anything you say _very_ seriously.

And I thought *I* was "active"...

Merc.

michelle’s picture

michelle
she/her
Primary language English
Location Wisconsin, USA
commented

Heh, I didn't mean to put you on the spot or call into question your past history. What it comes down to is this: I'm very active in the Drupal SN arena and there are a lot of people looking to me for what modules to use. If I say I'm using friendlist instead of buddylist 2 there's a good chance a lot of people will follow that lead. It's a responsibility I take seriously and I don't want to lead them down a dead end. I already put too many people in the direction of UR and now am upset about that. I don't want to make the same mistake again.

I like your response. It sounds like you are dedicated to this. I'll give the module a whirl and check it out.

BTW, I did, actually, look at the code but I didn't take the time to compare it against the code of the others to see if it was a fork. It was just a curiousity, after all. ;)

Thanks for the answer,

Michelle

mercmobily’s picture

mercmobily commented

Hi,

thank you for your time Michelle.
I have dealt with so many clueless people lately in the Drupal area (especially in the SN area, I must say), that I am finding it hard not to be biased.

A piece of advice: download UR, buddylist2 and friendlist and have a look around with three terminal sessions open. Then you will definitely _see_ what I mean by "look at the code"... err...

I personally think my module is a tiny step in the "Drupal as a social network system" project. I have the feeling that Drupal is completely missing the boat for example in terms of OpenSocial. I feel there should be a module, call it "OpenSocial Everything", that should turn any Drupal installation into an OpenSocial container. Before now, this was impossible because Drupal didn't even have a decent module to add other users as friends! (Doing this is important, because an application container needs to be able to "export" the list of friends of a user, amongst MANY other things).

When I see that module come to life, then I will see Drupal as a fantastic Social Networking tool.

But I don't think it's gonna happen. Google is acting as if they want Orkut & C to be great containers, but they don't seem to care about anybody else (well, apart from Myspace)

Bye,

Merc.

morbus iff’s picture

morbus iff
they/them
commented
Version: » 6.x-1.x-dev

Please run your code through coder.module before you comment on it its brilliance.

morbus iff’s picture

morbus iff
they/them
commented

Your use of drupal_access_denied() is wrong. See http://heine.familiedeelstra.com/access-denied-pitfall.

morbus iff’s picture

morbus iff
they/them
commented

Whilst the use of 'add' is ok to replace 'insert', 'del' is not. Everything else uses 'delete'; you should too.

morbus iff’s picture

morbus iff
they/them
commented

WHERE rtid='%d' is wrong. %d doesn't need quotes.

morbus iff’s picture

morbus iff
they/them
commented

The API is a bit... odd.

Drupal API's and functions tend to be either "object_ACTION" (node_save, node_delete, not delete_node, save_node, etc.). For invocations that modules can hook into, the module-available API tends to be "hook_objectAPI" with a passed in $operation. But, your API seems to be "ACTION_object", such as "friendlist_api_add_relation_post" and "friendlist_api_del_relation_pre". The use of the term "api" is also useless.

To make it more Drupal friendly, it'd be something like:

hook_friendlist_relations($op, $when);

where $op would be 'add' or 'delete', and $when would be 'pre' or 'post'. Then, a module only has to define one hook function and centralizes all the code. This is far more inline with Drupal's hook_nodeapi, hook_search, hook_block, hook_user, etc.

mercmobily’s picture

mercmobily commented

Hi Morbus,

All of your requests make perfect sense. I will apply them later today.
*Thank you*.

The code might look a little off spacing-wise because I developed it on a tiny eeePC and sometimes I just needed it to *look* right on my screen! But, OK, not a good justification. Sorry.

Merc.

alex.k’s picture

alex.k commented

Merc,

Looked at Friendslist schema and API. Overall it's solid and compares to the user_relationships API. The main differences are, to me...

* You've added a message that the requester can send (there is a feature request in u_r for this, too). There isn't a reverse function that user_relationships_elaborations provides, i.e. add a message by the requestee when approving.

* The other thing I see is that a user, once denied a friend request, cannot make the request again to the same user - u_r doesn't have it and that's a great feature IMO, a lot of people will be glad to have this.

The way you handle two-way relationships is different: u_r essentially creates two one-way records whereas you have one record with a flag for this. To me it's a toss up which is better... I think it's easier to query u_r because you always query requester to requestee and don't need to look for opposite direction. So the question 'how is A related to B' is one query, not two.

There is a safety check to prevent users from deleting a disregarded relationship... it would be better to implement it as a permission that, for example, site admins would have.

So the code is nice and once you get notifications going, will work for a lot of sites. Anyone looking at it would need to think a lot about their use cases, whether the way the model works will fit their needs. The choice of modules we have now might be good as social networking seems a sensitive subject, in that every site prefers its own way of doing things.

mercmobily’s picture

mercmobily commented

Hi,

Thanks for your message.
A couple of clarifications:

------------------
The way you handle two-way relationships is different: u_r essentially creates two one-way records whereas you have one record with a flag for this. To me it's a toss up which is better... I think it's easier to query u_r because you always query requester to requestee and don't need to look for opposite direction. So the question 'how is A related to B' is one query, not two.
-------------------

There is an extra flag in my table that is used precisely to prevent this "two query" problem (which is also a "views" nightmare).
The extra flag is set if it's a two way relationship. So, the two-query issue is not there.

---------------------------------------------------
There is a safety check to prevent users from deleting a disregarded relationship... it would be better to implement it as a permission that, for example, site admins would have.
---------------------------------------------------

To me, an API is an API... I don't have access to the code right now. However, there is a "force" flag so that the API can be told to "just do it, no fuss" even if the flag is there.

----------------------------------------------------
So the code is nice and once you get notifications going, will work for a lot of sites. Anyone looking at it would need to think a lot about their use cases, whether the way the model works will fit their needs. The choice of modules we have now might be good as social networking seems a sensitive subject, in that every site prefers its own way of doing things.
-----------------------------------------------------

I agree on this one.
Now... you seem to suggest that you think it's best to develop both user_relationships and FriendList, as separate modules. Their uses are different, the code is completely different... and we both seem to be willing to work on the codebase.

I am planning on working on the Workflow stuff very soon (as well as the access stuff, actually!). The "views" part scares me a lot... but I will get over it.

I think we need to be clear with this: do you think it's a good way to go, developing the two modules separately? Since you like the current code of UR, and I don't, and since the approaches are different and not mergeable, I think it's a fair way to go.

I think a sane way to go about it is to keep it "friendly" to the users by doing this:

* We link to each other from our pages.
* We develop import modules to import friend lists from each other
* We bounce off ideas an, when possible, code

Please let me know :-D

Bye,

Merc.

alex.k’s picture

alex.k commented

Hope it's getting clearer, for both of us.
Let's try to talk details of the API changes, and also I'll install Friendslist and try the UI. I assume you've tried u_r already so I'd like to know what issues, if any, you have with the UI.

We have a chance to 'do what's right' and avoid the fork, there is definitely potential here.

mercmobily’s picture

mercmobily commented

Hi,

I am totally happy to cooperate. I don't see FriendList as a "fork" though... I see it as a different API with a different approach :-)
I am going to bed now. I will work on answering your questions properly tomorrow.

However... I am still not quite clear on your idea. I wrote:

"I think we need to be clear with this: do you think it's a good way to go, developing the two modules separately? Since you like the current code of UR, and I don't, and since the approaches are different and not mergeable, I think it's a fair way to go."

But I never got a clear answer about this! (Or maybe I am to sleepy to see it?)

Bye!

Merc.

toemaz’s picture

toemaz commented

I'd like to throw in a question from a potential user (me) here. Suppose UR and FL do serve two different use cases, then I'm not able to define what module serves my specific needs best. Sure, you both put effort already in explaining the differences in code and therefore, some differences in the functionalities, but linking to each others module wont help much for a user to decide what to go along with.

So, let's start a wiki page to create a comparison table between features of the two modules. This way, potential users can see which module fits my specific needs.

mercmobily’s picture

mercmobily commented

Hi,

I can tell you from the start that *right now* FriendList doens't fulfil *anybody's* needs :-D

It absolutely needs to integrate with:

* Rules
* Views
* User Access

_Then_ it will definitely be useful. But, this might take a week or so -- if I get stuck on "Views", even longer.

I will make sure I update the wiki page, however :-D

Bye,

Merc.

mercmobily’s picture

mercmobily commented

Hi,

For the record, I have applied _all_ of Morbus' requests, which all made a _lot_ of sense.

Thanks Morbus.

Merc.

toemaz’s picture

toemaz commented

The wiki comparison chart is getting filled: http://groups.drupal.org/node/14625
Feel free to further modify it.

Alex, Merc, if you feel it is useful, perhaps you can link to this wiki page from both your project pages.

mercmobily’s picture

mercmobily commented

Hi,

I was going to write what I thought about User Relationships, and how we could converge.
I find writing this post very difficult to write. I am biassed. It is no secret that I don't like User Relationship. However, I feel like crap just because I am _saying_ this. I cannot write a slamming post, knowing that I am criticising heavily another person's work.

Alex, can we catch up in a gtalk session? It's more "personal", and it will get more across through feedback etc.

Sorry guys, I just can't.

Merc.

mariusooms’s picture

mariusooms commented

+1 for Views/Rules support
+1 for a User Relationships 2 branch

Having Ajaxified Friends/Friend/FriendList makes it confusing and unnecessary, so I really hope efforts can be consolidated into a User Relationship 2 branch.

Personally I do have had good result with BL2 on the D5, but on D6 development is going extremely slow. I do apologize that I can't help with code (other than debugging), so I might not have much weight to argument. However I am an end user that will rely on the maintainer of a module to provide good support. I don't see that as of yet with any SN module, at least not consistently. Many times we are left in the dark with half finished projects that only served the maintainers needs and are abandoned afterward!

Therefore if you and Alex could come to terms and co-maintain, would make a much stronger platform than two individual projects with a single maintainer.

Kind regards,

Marius

icecreamyou’s picture

icecreamyou commented

+1 for a UR 2 branch

I'm a developer and I've already written a ton of custom code for my websites to integrate with UR. There's no way I'd switch to FL if it were a separate module, because the cleanliness of the code makes absolutely no difference to anyone who's not developing the module itself. (To clarify: my code doesn't use the UR API, it just gets whatever it needs from the DB directly. Mainly, I'm missing a function that will return an array of UIDs for users that are a given relationship type of the current user.) But if FL became a new branch of UR, I probably would go through the process of upgrading just because the code would be better supported at that point.

Although it's all kind of a null point for me, since the sites I use UR on are all 5.x still.

ajayg’s picture

ajayg commented

@toemaz
Since you wanted to focus only on D6, I didn't modify Wiki. But a very important criteria for an end user (webmaster/site owner) is installed base. I am not sure how much installed base U_R has for D6, but there is a sizeable base for D5. Somehow this information is missing in the Wiki page if we just focus on D6.

mercmobily’s picture

mercmobily commented

Hi,

Friendlist will be a separate module. It doesn't look like it will be the UR 2. branch.
FL's API is redeigned, and so is the DB structure.

Alex and I will share ideas and possibly code, but they will stay separate.

Bye,

Merc.

icecreamyou’s picture

icecreamyou commented

...why, apart from merc not liking UR? They do almost exactly the same thing, they're just different codebases.

mercmobily’s picture

mercmobily commented

Hi,

the problem is in the "just". And in the fact that programmers out there write programs which read and write straight from database tables rather than using an API.
FriendList is a different codebase. This discussion is on how to make it better, now "why two APIs". I frankly need to spend time coding, rather than discussing this topic.

If you want to help User Relationships, please contact Alex -- who is very capable. This is the wrong forum -- sorry.

Bye,

Merc.

mercmobily’s picture

mercmobily commented

Hi,

@mariusoom:

--------------------------------
However I am an end user that will rely on the maintainer of a module to provide good support. I don't see that as of yet with any SN module, at least not consistently. Many times we are left in the dark with half finished projects that only served the maintainers needs and are abandoned afterward!
---------------------------------

I have been the maintainer of Drigg, Extra Voting Forms, User Karma and Comment bury Promote for 1 year. Check out their issue list.

I will do my best to keep it going. I will not quit. The codebase will be excellent. And bugs will be resolved.
If I can't do it anymore, I will make sure I have a different maintainer.

Merc.

icecreamyou’s picture

icecreamyou commented

Merc, that's my point. You wouldn't have to change any code; there would be no merging involved; quite literally, the only difference would be a name change for Friendlist.

...but suit yourself. You apparently did this to help the community but it's going to end up hurting if everyone is confused which module to use.

mercmobily’s picture

mercmobily commented

Hi,

The current codebase of Friendlist (which will include the current database structure, the current source code and the current API) is now being maintained by Alex. So, User Relationships, the "original" one, is not going to die.
Since:

1) Friendlist has a different codebase, different DB, different API
2) Alex, User Relationship's new maintainer, likes the current DB, API, codebase and will support it

It looks like FriendList and User Relationships will be two different projects.

Bye,

Merc.

mariusooms’s picture

mariusooms commented

Alright Merc...it is very clear now, I guess if anyone still questions the _why_, they should read this discussion again.

I look forward how you will work towards making FriendList a successful module, especially I like that you are looking to depend on Views and Rules, which also have very solid maintainers and reputation.

See you in the issue queue.

Regards,

Marius Ooms

mariusooms’s picture

mariusooms commented

Do you also plan to have helper modules? For example, modules that extend the basic api, such "Friends in Common", "Potential Friends", "Friends Route", "Friends Privacy", "Friends Activity"? Off course Activity is also in the process of being ported, but I don't know if you are interested in using that as well.

I realize these request are no where on the horizon yet, but it could help build a road map for people that are currently deciding where to invest in.

Regards,

Marius

mercmobily’s picture

mercmobily commented

Hi,

I am planning to interface with Activity. I actually wrote the code, only to realise that Activity only exists for Drupal 5. UGH!

And yes, I am planning on writing the "friends in common", "route" etc. That's when we (as in people who maintain these modules) can share ideas and code.

But don't take my word. Just keep your eyes open and see how the modules develop.

Bye!

Merc.

mariusooms’s picture

mariusooms commented

Oops, I edited my question while you already responded, so I'll ask it in a new post.

One thing that I personally would really need, and depend on, is "Friends Privacy". Much like Facebook friends system that only allows viewing the content of Friends, else a teaser block is displayed when any content of that user is being accessed. I have mentioned this in the isue queue for both UR and BL2, but it does not seem high on the wanted list which strikes me as odd. Especially since privacy is fairly important in SNS these days.

Is that something you thought about as well? Or if anything could be developed later on?

Regards,

Marius

mercmobily’s picture

mercmobily commented

Hi,

This is something high in my *personal* list.

Access, Views and rules are hight up -- even beforee "friends of friends" etc.

Bye,

Merc.

mariusooms’s picture

mariusooms commented

Hi, that sounds great. Even though I won't be of to much help regarding code or whatever, I will be able to test extensively and provide feedback. I'll be watching development closely.

Regards,

Marius

mercmobily’s picture

mercmobily commented

Hi,

I talked to Alex, the maintainer of User Relationships, last night (for 3 hours!).
We clarified a _lot_. There were some things I didn't know, some ideas I passed along, and a final _real_ understanding of our modules' role.

Since this module is officially in its existence, I am closing this general discussion issue -- from now on, issues will be treated "normally".

However, I am updating the project's page to clarify exactly what is what, and why.

Bye,

Merc.

mercmobily’s picture

mercmobily commented
Status: Active » Fixed
mercmobily’s picture

mercmobily commented

Hi,

This issue will clarify things a lot:

http://drupal.org/node/305031

@Iscreamyou, @mariusooms: I hope this clarifies absolutely everything! Sorry about being a little unwilling to answer the "why the fork" question.

Bye!

Merc.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

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

ClearXS’s picture

ClearXS commented
Status: Closed (fixed) » Needs review

To me its not clear at all, right now; after having red both project pages, several affiliated, necessary and depending modules, the wiki, this discussion.

How could I decide without installing both on different sites and make them a copy of each-other, except for the different friends/user-relations modules and spend half a year practising both?

Friends-list seems to work with AJAX popups but the maintainer of popups and a second popups module is giving up while it still is a bit actual for now. User Relations and AJAX? The wiki says yes, but where is the info and just as nice as Friendslist?

And how about Modal Frame and affiliated modules? Popups refers to this project and seems(?) to have some advantages. But I don't read on User relations nor on Friendlist that this module is used.

Buddy lists project page advices Friendslist??! But there no explanation is given why not User Relations?

Then friendslist only has a dev version from 2009-Jun-24, while User Relations has almost a final release and the latest release of 2010-Jun-01.

So friendlist seems to be the sinking ship, while it never came to the point of really threatening the position User Relations had (download statistics).

Or is this ship in the dockyard now and will come with the newest features soon?

If not, then maybe friendlist developers join the user-relations project to get their features there, instead of all that work gets lost in time!

(for now I will de-install Friendslist and Popups and continue only with UR and Modal Frame, being in the building stage of a very module rich site)

vm’s picture

vm commented

Friendslist hasn't been touched in almost a year. I'd say UR is a safe bet.

icecreamyou’s picture

icecreamyou commented
Status: Needs review » Closed (fixed)

FriendList had a good run, but it basically hasn't been maintained for a year. I haven't used it in a year either, so I have no idea whether it's stable, but my guess is that if you really wanted to use it it would probably work fine.

The differences between FriendList and User Relationships are trivial. They mostly have to do with how the code is organized.

User Relationships is the current market leader. The major challenger is Flag Friend. There are significant differences there, primarily that User Relationships allows multiple relationship types whereas Flag Friend only allows the "Friend" type, and UR allows one-way relationships where FF only allows two-way relationships.