Friendlist driven by Flag module

Hi Irakli,

Granted Flag has a very powerful API. Currently there is already a module building on that api called Flag Friend. It be worthwhile to do some comparing testing against that module and see how it stacks up.

In case there are no benefits to use the current friendlist api over the flag api, I would suggest abandoning this module and merge with Flag Friend. I think otherwise we create some serious duplication.

However if there are key differences, which I can think of one or two on top of my head, it can stay as is. For example, I'm pretty sure you still can't create a friend feed with the flag module. Also, I don't know if there is an access system in place. Both of these might have changed the last time I looked.

I'm a huge Flag fan and have no problems with a module build on their api, which has rock solid maintainers, the best among Drupal if you ask me. However it would be better to join forces with a module that already is pursuing this course of action, aka 'flag friend'.

I'm looking forward for someone to do some solid side by side comparison.

Regards,

Marius

Wow! Sounds pretty cool and is definitely a crucial change in the architecture.

I like the idea of "flagging" someone as a friend, hence the reason someone may have come up with the "Flag Friend" module that Marius mentioned. Also, Flag Friend looks pretty mature. And with the Flag module, it looks like there might be other options that could be used. For example, could I (not that I would) use Flag Weights to make a list of favorite/best friends?

Just curious, do you have any thoughts on the friend feed and access system that Marius mentioned? Would these features be custom modules or extensions/additions of Flag or Flag Friend?

I must say I like the Frendlist module and use it today. Thanks for your work. You guys are doing a great job!

Jarod

Ah, it did cross my mind just last night as well. Really glad it comes from the maintainer himself. I love you guys. Thanks

Merging with Flag Friend would eliminate some of the duplication. In this space, it's pretty much down to User Relationships, Flag Friend, and Friend List. If FF and FL merged, then it would only be two modules for other maintainers to integrate with, which cuts out 1/3 of the work.

This is an old issue... I just stumbled on it by accident. Has any more thought been giving to the idea?

Michelle

Yeah, I've resigned myself to the fact that UR/FL are going to continue doing the same thing on different paths. But merging FL/FF would at least cut it down to two modules to deal with. It's not perfect, but it's better. There was a time when I wanted to see FL come out on top. Unfortuantely your predecessor ruined that but you seem like a more reasonable fellow. A merging with FF would make me take a second look at FL, at least. Not that I expect you to do anything to please me, of course, but I think a merger would benefit a lot of folks by reducing user confusion and the workload of maintainers to integrate.

Michelle

Huge, yes, but I disagree with not feasble for a small team considering I'm doing it by myself working part time. ;)

I'm not suggesting forcing you to join up with FF. I wouldn't have initiated this discussion. I was just throwing my +1 onto it and curious if any progress had been made. :)

Michelle

Hi,

I looked at it very carefully when Michelle first suggested to merge FriendList with Flag. At that time, I had the whole codebase in my head and actually coded the parts that needed to be done. I remember that there was a huge stumbling block, but frankly I can't remember what it was.
There was a time when I wanted to see FL fully integrated with Drupal as much as possible and was willing to bend over backwards to follow Michelle's advice and suggestions. Unfortunately Michelle ruined that and I ended up deleting that flag code (which worked although there was something missing -- again, I can't remember what it was...).

However, I am definitely happy to help you as the new maintainer. I remember it being feasible to hack FriendList to use Flag.

Merc.

Hi,

Hey, I just saw the code of flag_friend.
sirkitree really seems to know what he's doing here. His code is good. I *think* he looked at FriendList's codebase for inspiration (about the concept of "statuses", level of caching, etc.), but I might be wrong. There are some very neat things (like :// always keep these in the same order", line 261 -- I wish I had thought of that) and the code in general is well structured and generally a pleasure to look at.

Plus he had the *very* right ideas about using Flag's hooks to then create statuses for relationships. Not sure I would have been smart enough to do it quite so right.

After looking at that code, I think FlagFriends is the best way to go if people want to use Flag as a backend for their user relationships. Mind you, I haven't actually _tried_ the module, but it looks very promising.

Wow, so now it's User RelationShip, FriendList and Flag Friend... I guess a few people out there are having stomach cramps :D

Irakli, let's get Flag Friend to adhere to the generic API we designed a while back. I still think no User Relation module should come "on top", but that the most important thing is that other Drupal modules can find out what the relations are regardless of what module is being used underneath. I think the generic API was the greatest achievement after all this.

Bye,

Merc.

Hi,

Crap, I wrote a huge response on why using flag is unpractical, and it's not here!!!
My god. Gotta rewrite the whole thing again. Here is the shorted version:

* Lack of "message" field in the flag db. This makes it really hard to pass on messages
* Lack of the tw_rejected_flag (can't remember the exact name) in flag. This is a VERY important flag, because it allows people to refuse relationships.

A possible solution would be to write a support table for FriendList to cover the lack of this data. But then Views would be probably nightmare-ish to use, with the extra tables etc. And most of the benefits of the intergration would be lost...

This is the short version of the long post I wrote... same substance :D This should complement my previous message about the flag_friend module. Sorry about this message being a bit short...

After seeing flag_friend, and remembering what shortcomings there would be using flag, I thing it would be the wrong way to go about it.

Merc.

Hi,

Since there is already a (new) module out there based on Flag, and since there are pretty nearly-insurmountable problems with using Flag for the problems I mentioned above, I think this will have to be a Won't Fix.

On the bright side, I am talking to the developer of FlagFriend, and helping out so that FlagFriend works with the Universal API Alex and I designed a while back.

Duplication, this way, is healthy. I am glad things worked out.

Merc.