phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [phpGroupWare-developers] Nested db-objects


From: Maât
Subject: Re: [phpGroupWare-developers] Nested db-objects
Date: Sat, 24 May 2008 16:23:04 +0200
User-agent: Thunderbird 2.0.0.14 (X11/20080504)

Sigurd Nes a écrit :
As Maât very elegantly wrote (he is my hero) - we need the freedom to do studid 
things.

Please Sigurd, don't try to use my words for more than i intended to mean (sorry i'm going to loose the "hero" status)

I explained that framework should allow to do things... even stupid but i also said that was for M. Doe apps... for core apps i consider doing things stupidly should make apps be granted a quality label like "low level" and/or provided as a third party separate package instead of included in core phpgw package.

A framework allowing to do things in a "quick-and-dirty" manner would bring more people willing to code tiny apps *for themselves* and later perhaps bring a few valuable and "quality aware" developers... but for core apps we should set high quality standards as a requirement.

i bet nobody here wants slow and ressource consuming apps in phpgw that wouldn't give a good example :)

That means db cloning shoud be avoided like plague in core apps (even if not hard locked) and only accepted in specific cases when this is the best (or least ugly) solution.

And it is not good when it - BANG! - stop working - and we have to 
speed-rewrite large portions of the code.

The brutal way of switching from one option to another could have been replaced by a prior notice and a negociated deadline so that everybody can study the side effects and plan the rework in a reasonable, NOT INFINITE, time.


A successfull implementation will (and already has)  provide resources back 
into the project - so that should be a good thing for phpgroupware in the long 
run.

(Sorry my english is too poor and i didn't understand that)

I will take all advice on code style seriously - but it shouldn't be forced - 
and it can't be all implemented at once.

Once again, i said it shouldn't be locked *at code level* .... but if i didn't make myself clear it should be :

-- discouraged for  M. Doe or M. Smith app
-- nearly forbidden for standard apps

AND DEVELOPERS (me included) SHOULD LISTEN AND ACCEPT QUALITY TEAM REQUIREMENTS AND COMPLY WITH THEM

So - can I please have the nested db-objects?

Regards

Sigurd
If you ask me (but i'm just giving my point of view) i would say : *temporarily* yes with the following conditions :

1) we should rewiew/clean/optimize rather quickly the code modifications you suggested so that clone creation and clone release are well controlled (and the number of clones limited) or better if possible : replace the cloning by a cleverer approach that allows multiple requests to be parsed without conflict (and then plan for a replacement of clones where they were used).

2) we should track very seriously :
-- un-needed clones (created and not used)
-- cases where a slight code rework could avoid the clone approach
-- too early cloning
-- too late releasing

3) We should fix the above cases in apps (included ged and property) with a rather high priority in a reasonable time.

regards,
Maât






reply via email to

[Prev in Thread] Current Thread [Next in Thread]