[geeklog-devel] SOCNET

[Randy Kolenko]

> I still think the core modifications should already be in place
> before Summer starts. I've started doing a diff and it is not all
> that hard. It's more an issue of tracking down all the group table
> references and checking them. (Oh, and I've discovered there's no
> need to modify grp_gl_core at all. Simply adding grp_owner is enough.
> If grp_owner is zero, the group is maintained by the group admin
> feature only. If the grp_owner is non-zero, only the user with that
> uid can access the group. Thus the socnet plugin would need to ensure
> that all group manipulation occurs to groups with non-zero owner
> records.)


Ok.. I just added the GL core modifications to the GSoC project as you
just never know what will be out the door at that time.
The student could easily use the "bonding period" to troll through the
code looking for issues with the group change.


> 
> I would assume the plugin would hook plugin_getuseroptions_socnet


Correct.  


> 
> SOC_createAlert($uid_to, $uid_from, $objid, $plugin, $state =
> 'UNSEEN') returns list($state, $datetime_created)
<<snip>>
> SOC_ignorePluginAlerts($uid, $plugin) allows the user to ignore
> annoying plugins


Sure.  All good ideas. The implementation of all of the socnet methods
will undoubtedly be tweaked over time.  Keeping them hooked based is the
best approach.

Students also have to keep in mind about how to implement the security
for a plugin.  A variety of SOC_checkSecurity, SOC_secureContent etc.
will have to be created in order for a plugin to utilize and subscribe
to socnet security.

I would like to see student proposals actually have some of this type of
approach thought through and fleshed out.  Otherwise there will be
simple regurgitation of what we've typed into these threads :-)