Greetings - I don't generally post here, but I read your comment re: social networking and I didn't want it to fall through the cracks.. . so I just wanted to give you a little bit of (hopefully helpful) guidance, regarding which direction to take, in case you're looking for some. On dev / your 5.26.06 posting / it seemed as if you were trying to decide whether to go for developing either... (1) "social networking" capabilities, a la orkut -- for drupal end users -- (2) or network analysis -- for drupal admins. Personally, my vote is for polishing up the social network capabilies of drupal for end users, a la orkut. [In fact, (1) might be a prerequisite for a successful deployment of (2). Reasoning: without adequate SN capabilities, there might be little network infrastructure to analyze.] :-) Anyhow, that's my current interest and bias and in case you've elect to go that route, I've done some investigating of what drupal already has on offer, so could hopefully give you a bit of a head start. There's definitely stuff you can build on, although there's also quite a ways to go. The principal social networking tool available in Drupal, imho, currently, is Drupal's "buddylist.module" which is supposed to be the rough equivalent of the common "friends" function you find on all the popular SN sites, orkut, myspace, etc. The module is well written and well documented. So, I would consider building off of it. However, this module has two significant drawbacks, (1) First, under its current cvs setup, *buddy relations are not symmetrical*. That is, if A is buddy of B, it does not imply that B is buddy of A. That is, buddylist treats friendship relationships as *directional*, rather than *mutual*. This creates some confusing scenarios -- for example -- under the current setup, you can have the following situation: "Jack is buddies with Jill, but Jack is not buddies of Jill, where as Jill is not buddies with Jack, but Jill is buddies of Jack" [Did you get that? ;-)] Although there might be some very unusual special cases where a unidirectional friend relationship might be useful, this is clearly, generally, not the common semantic case. (2) Second, currently, *buddy relationships may be unilaterally determined*. That is, A can unilaterally decide to declare that he is buddies with B, regardless of B's consent. That is, for example: "Quasimodo, the crazy stalker, can decide *on his own* that he's buddies with Esmerelda, even though Esmerelda has placed a restraining order on Quasimodo." ;-) Again, this unilateral capability is not standard in the common usage of buddy relationships as a social networking tool - and for good reason, I believe. Generally, buddy relationships are mutually and *consensually* determined. There are other more superficial issues regarding the polishing of buddylist, but these two issues strike at the core of it, and should be tackled first, imho. A solution to these two issues above has been posted as a patch here http://drupal.org/node/11892 -- it is patch that I wrote -- with help from RobRoy -- and functions without a hitch on my site, www.ithou.org . This patch replaces the "asymmetric" / "non-consensual" framework with one that is "symmetric" and "consensual". It is still awaiting review. I imagine that you could assist in that polishing and review process and as part of your SoC contribution, you could help move Drupal and buddylist into a more solid social networking platform. Should this be of interest to you as part of your SoC project, please do not hesitate to contact me. Regards, Albert albert [at] ithou.org
Generally, buddy relationships are mutually and *consensually* determined.
That really depends if you take the word "buddy" to mean friend. I think the buddylist.module might be better named "authorlist.module." It gives users an opportunity to track other contributors to the site ("authors") and see what they have written. In a practical sense, the need for mutually established relationships is only important if you want to control access: access to posts (see organic groups), access to profile information (see access control), etc. FWIW - I think you might want to look into organic groups rather than buddylist. OG already has the framework to do access control. Buddylist does what it does well - I'd hate to see it cluttered. Of course, if you're going to fork, choose whatever code you think you can use most easily. But before you go down that road, consider building a module on top of OG - I think you'll appreciate the work that has already been put into OG. -Mark
Also have a look at profiles-as-nodes on groups.drupal.org We are building a module/api/library that allows you to treat user-data as nodes. And node-node relations, esp with taxonomy, is very easy. so youll get a lot for free if you require this project into yours. Feel free to post any concerns, ideas and/or requirements in that groups thread. http://groups.drupal.org/profiles-as-nodes Bèr Op zondag 28 mei 2006 23:37, schreef Albert Wong:
Greetings - I don't generally post here, but I read your comment re: social networking and I didn't want it to fall through the cracks..
. so I just wanted to give you a little bit of (hopefully helpful) guidance, regarding which direction to take, in case you're looking for some. On dev / your 5.26.06 posting / it seemed as if you were trying to decide whether to go for developing either...
(1) "social networking" capabilities, a la orkut -- for drupal end users --
(2) or network analysis -- for drupal admins.
Personally, my vote is for polishing up the social network capabilies of drupal for end users, a la orkut.
[In fact, (1) might be a prerequisite for a successful deployment of (2). Reasoning: without adequate SN capabilities, there might be little network infrastructure to analyze.] :-)
Anyhow, that's my current interest and bias and in case you've elect to go that route, I've done some investigating of what drupal already has on offer, so could hopefully give you a bit of a head start. There's definitely stuff you can build on, although there's also quite a ways to go.
The principal social networking tool available in Drupal, imho, currently, is Drupal's "buddylist.module" which is supposed to be the rough equivalent of the common "friends" function you find on all the popular SN sites, orkut, myspace, etc.
The module is well written and well documented. So, I would consider building off of it.
However, this module has two significant drawbacks,
(1) First, under its current cvs setup, *buddy relations are not symmetrical*. That is, if A is buddy of B, it does not imply that B is buddy of A. That is, buddylist treats friendship relationships as *directional*, rather than *mutual*. This creates some confusing scenarios -- for example -- under the current setup, you can have the following situation:
"Jack is buddies with Jill, but Jack is not buddies of Jill, where as Jill is not buddies with Jack, but Jill is buddies of Jack"
[Did you get that? ;-)]
Although there might be some very unusual special cases where a unidirectional friend relationship might be useful, this is clearly, generally, not the common semantic case.
(2) Second, currently, *buddy relationships may be unilaterally determined*. That is, A can unilaterally decide to declare that he is buddies with B, regardless of B's consent. That is, for example:
"Quasimodo, the crazy stalker, can decide *on his own* that he's buddies with Esmerelda, even though Esmerelda has placed a restraining order on Quasimodo."
;-)
Again, this unilateral capability is not standard in the common usage of buddy relationships as a social networking tool - and for good reason, I believe. Generally, buddy relationships are mutually and *consensually* determined.
There are other more superficial issues regarding the polishing of buddylist, but these two issues strike at the core of it, and should be tackled first, imho.
A solution to these two issues above has been posted as a patch here http://drupal.org/node/11892 -- it is patch that I wrote -- with help from RobRoy -- and functions without a hitch on my site, www.ithou.org . This patch replaces the "asymmetric" / "non-consensual" framework with one that is "symmetric" and "consensual". It is still awaiting review. I imagine that you could assist in that polishing and review process and as part of your SoC contribution, you could help move Drupal and buddylist into a more solid social networking platform.
Should this be of interest to you as part of your SoC project, please do not hesitate to contact me.
Regards,
Albert
albert [at] ithou.org
-- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc Drupal upgrade repareert kritiek beveiligingslek: http://help.sympal.nl/drupal_upgrade_repareert_kritiek_beveiligingslek
participants (3)
-
Albert Wong -
Bèr Kessels -
Mark Fredrickson