[geeklog-devel] GSoC 2010 is on

[Vincent Furia]

>
> Why duplicate the group structures?

Because Geeklog's group infrastructure is overkill for user groups.
Presumably, user groups will only be granted read access (no
edit) and only to the owning user's content single user's. User groups also
don't need to be nested.

Adding user groups to the core is going to make many of the SEC_ functions
much more complicated, slowing them down for many sites that won't use the
functionality. Also, more complicated code == more potential for bugs.

Also, if you use the existing group structure on most tables (the 6 fields
COM_getPermSQL deals in), you're actually going to lose flexibility. Those
items only allow one group assignment. If you set that to a user group for
read access, you lose the ability to have multiple people edit an item.

If the socnet plugin has to implement its own group handling code and its
> own permissions code why bother putting it on top of Geeklog? What is
> Geeklog providing besides login services at that point?

This point is obtuse. Geeklog will still provide much more than just login
services.

The code change I'm describing only involves tightening the existing code to
> make sure it makes "2" groups invisible on the admin side. *No other
> changes are needed to support this idea.* The alternative involves the
> socnet author writing a complete group system and permission system from
> scratch, basically duplicating a bunch of code that's been in production for
> around 10 years. You really think that makes more sense than enhancing the
> existing code in a few places?

I think you're underestimating what core code will have to change to support
this idea. I'm not saying we shouldn't put this into the core, but you're
completely ignoring good, valid arguments to put this new functionality into
a plugin. What is wrong with examining both options after there design
implications have been fully evaluated (benefits and drawbacks) and deciding
on that basis?

-Vinny

On Tue, Feb 16, 2010 at 9:10 PM, Joe Mucchiello <joe at throwingdice.com>wrote:

> At 05:55 PM 2/16/2010, Vincent Furia wrote:
>
>> Also, why is it the case:
>> But the basic call to COM_getPermSQL must support users' groups or a
>> social plugin is a non-starter.
>>
>> With a plugin model, other plugins can be enhanced to check core geeklog
>> group permissions as well "user groups".
>>
>
> Why duplicate the group structures? Why duplicate the code in
> COM_getPermSQL in a plugin? There already exists the 6 permissions fields
> found on most tables. Why not take advantage of the existing infrastructure?
> Why not take advantage of the existing and well known best practices? If the
> socnet plugin has to implement its own group handling code and its own
> permissions code why bother putting it on top of Geeklog? What is Geeklog
> providing besides login services at that point? The whole point of building
> social networking on Geeklog to be able to take advantage of stuff Geeklog
> already provides.
>
>
>  If user groups aren't supported, plugins can gracefully degrade to only
>> supporting COM_getPermSQL.
>>
>
> Or there can just be one well-known, well-supported API that does it all
> for you and you don't to check first to see if this is a socnet enhanced
> object or not. The existing code just works. No need to gracefully degrade.
> The grace is built in.
>
> The code change I'm describing only involves tightening the existing code
> to make sure it makes "2" groups invisible on the admin side. No other
> changes are needed to support this idea. The alternative involves the socnet
> author writing a complete group system and permission system from scratch,
> basically duplicating a bunch of code that's been in production for around
> 10 years. You really think that makes more sense than enhancing the existing
> code in a few places?
>
> I would offer to write the patch but I don't have a good track record with
> getting my patches accepted into core.
>
>
> ----
> Joe Mucchiello
> Throwing Dice Games
> http://www.throwingdice.com
>
>
> No virus found in this outgoing message
> Checked by PC Tools AntiVirus (6.0.0.19 - 10.004.153).
> http://www.pctools.com/free-antivirus/
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20100216/782d009f/attachment.html>