2014-02-24 19:04 GMT+01:00 Doursenaud, Raphaël <address@hidden>:
Thanks Laurent for the breakdown and very thorough answer.I understand most of it but two points I'm particularly interested in bothers me :
- SQL parameterization
- i18n/l10n/nls
I really have a hard time living without SQL parameterization.Maybe it's because I'm too stubborn and it saved my ass so many times.The mysqli driver we mainly use allows parameterized queries.
Can't we add a parameterization layer on top of our wonderful abstraction layer?
Why not, lets talk about this during devcamp.
I'm also a bit surprised by your position on PDO, have you had a look at it lately?
Yes i did. Still not the solution we need.
for example PDO was designed thinking DML commands, but not DDL and DCL commands.
See page http://www.orafaq.com/faq/what_are_the_difference_between_ddl_dml_and_dcl_commands for differences.
Some enhancement were done to support TCL but it still no enough.
We need DML + DDL + DCL +TCL
For example try to get the return code of an error when creating an index using pdo. You will get a different values depending on database you use. We don't want that.
Try also to create foreign keys after creation of table. Syntax is not correctly supported by all databases even if using PDO.
Note that the dolibarr driver for sqlite was started and is using PDO. But technical limitation make not possible to finish it (for example it is not possible to create some keys AFTER a table was created, and we need this for upgrade process). There was other minor things we add to override but the dolibarr driver was able to compensate. Main problem are DDL and DCL commands.
It dramatically improved since its first introduction when it was slow, buggy and unreliable.But I can live without it.Now on the native language support side of things.I may be biased by the HUGE number of projects I contributed translation to that uses gettext or some derivative.This helped me realize that there is a lot more to it than just swapping strings off an array. If it was that easy, gettext would not exist.How do we handle plural forms with our current framework? Did you know Russian, for example, had 3 plural forms with some complex rules to it I still fail to understand.
Supported by different keys
What about words order? Gettext allows placeholders and handles this nicely.
We don't really need this. gettext need this because it use the english version translated value as the key. That is a stupid way of working. Dolibarr use a generic keyword as a key and english value. So we can make different sentences
What about date, number, measure and currency formats?
Also supported. Better than gettext
I don't see where Dolibarr translation framework is more powerful here. Could you give me some pointers?
- with dolibarr, when a translation is not found for a variable language it is not necessary the english that is used. For example if into mexico, translation is not found, dolibarr will use the spanish and english only if spanish not found. This bring better translation for local translation even for countries not found.
- When we change a string into english, we don't have to change the code everywhere the string is change. We only change english. gettext use the "translated value" as the key. Dolibarr use a key so fixing a type does not need to change code and above all does not return to all other translators there is something to fix on their side.
- gettext is not compatible with a lot of external translation tool (not opensource or not linux tool, but translator need to use them a long time before using transifex). Most translators are just non opensource and non linux users but windows users.
- gettext was hanging on some PHP on windows installations.
- gettext need dependencies.
- gettext memory usage was higher that dolibarr
- dolibarr translation system can manage translation cache in PHP memory or external memory (even if not used because need high technical knowledge to activate this). gettext cache is using apache.
- gettext hangs seriously on IE servers (may be less now), but even with some exotic apache installation.
- in php, gettext use environment variable we must switch each time we need a translation into antoher language. Because we must be able to use multilanguage that need a language for some part of This is just an awful thing. A software must never change external environment on the fly. This make coding more difficult when using mutlilanguage code that need to execute part of code with a language and other with another language like when we must generate a pdf into a language without outpout into a second one (and log output into a third one). This make also gettext just not working with some very strict PHP configuration on some cloud hosting provider (where php is compiled with option breaking putenv, setlocale for security reason but it is just an example) .
- Also using environment variable make code more complex because you can have only one value for one environnement variable set at once. We need several in some cases (like when generating a pdf into language of customer that differs of language of user generating the pdf).
- gettext is not able to manage languages that are "a mix" of two language (i mean for a language codification that does not exists into standard language iso classification but that exists into "business" world for some countries. for example Dolibarr create language en_SA for that (that does not exists in ISO but exists in real business life for arabi saudia).
- gettext works only when language code exists. Some countries need a language that exists but with a variant specific to the country when language is speaking only into this country. I can't remember what was example like this but we have one, may be russian languguage when country is ukrainia. Dolibarr can support this very rare case but required again for business.
There was a lot of other things like that, they were discussed when we decided to abandon the switch to gettext 6 or 7 years ago. So list is not complete (and i remember it was very longer list than that. There was at least 10 or 12 more reasons but i prefer not spend time to search into archives and lose my time. I am just happy to see we are able to do everything now we need, even things other projects can't do, so i have no reason to work again on this.
Don't even get me started on CJK and RTL support which are way beyond the scope of this exchange but still has to be introduced sooner or later.
They are supported. Try hebrew language (even if it is not maintained by any translator or by css developers)
I'm eager to see your arguments and would love any pointers to old discussions on the subject. I'm quite new to the community after all…
You welcome, this may remind also to everybody reason of some very very old choices.
Cheers,
2014-02-24 17:54 GMT+01:00 Destailleur Laurent <address@hidden>:2014-02-24 16:24 GMT+01:00 Doursenaud, Raphaël <address@hidden>:
Indeed, this is an important reminder.I'm guilty as much as anyone of working on new features without fixing enough broken code.But, as you may know, it's relatively easy to get paid for working on new features while it's nearly impossible for bug fixing..On the other hand, the Dolibarr codebase suffer from an old and intricate coding structure that don't help fixing bugs efficiently and keeping them that way.We already prooved that making fix with dolibarr need 3 times less times than any other projects using more complex coding structure. I don't think this is the reason.IMHO, even before squashing bugs, it needs a big overhaul of its internal structure.From the top of my head, here are the issues I'm constantly fighting with :
- Inconsistent coding style (cf. Florian post)
Code is fully compliant with our PSR (see answer I made to florian). 100% of checkstyle check of our PSR is success.PSR of dolibarr is described into wiki documentation.
- Relatively Inefficient bug tracker. (Personal opinion)
I am happy with bug tracker. But if you can suggest best thing, it is welcome.
- Classes inconsistency and missing a lot of utility methods. (See next point)
Sure, we can enhance this
- Duplicated code all over the place that should be factored into the native objects. This makes maintenance a nightmare.
Sure, we should enhance this.
- Inconsistent API with half french naming and all.
Sure, we must enhance this.
- Not using parameterized queries and field tested database drivers such as PDO.
We are already using database abstract layer that is 10time better than PDO. We forget PDO a long time ago (it was first choice done) because it was not enough powerfull for us. There was already a lot of exchange on this. We don't need PDO. PDO is not enough powerfull for us, our database abstract layer is really great making dolibarr the only project that provide technical upgrade possible by end users with no technical knowledge and with no need to think to database. We develop for mysql and it works everywhere, even upgrade process. Also we have a unique error management (not other abstract layer), and we have an automatic inclusion of transaction (not also available with other framework) and more...
- Not using a internationalization/localization toolkit such as gettext
Same than PDO. Get text is not enough powerful/featureful for dolibarr. We have our translation framework that works really better. There was also a lot of exchange to proove this.Currently integration with transifex is 100% complete with automatic sync from transifex so i don't think we need something else. Transifex provide all what we need.
- Legacy libraries with bad design decisions (Yes, I'm looking at you PDF documents)
Can you give more example ?
- I forgot a lot of other issues.
I wanted to keep that discussion for the DevCamp but since I already opened the pandora box, here's my thinking:As you stated, Dolibarr is now a mature piece of software.Since removing code is the best way to reduce bugs, maybe it's time to start a disruptive 4.0 development cycle with ambitious objectives and set everything else on maintenance only mode.Here's what would be my go-to list:
- Unify coding style (PSR preferred here because it's community driven, clearly defined and sees massive adoption).
- Reduce codebase by redesigning objects and nicely factoring existing code.
Sure, welcome.
- Fully embrace OOP and other modern PHP features.
- Parameterized SQL queries and unified database driver (PDO).
See previous answer.
- English only code and comments.
Sure
- Gettext translation support.
See previous answer
- Get rid of legacy libraries.
Sure.
- Break the API, yes, let's break it bad for the greatest good, it's a new release after all.
- HTML5 pages.
All pages are already currently HTML5/CSS3 pages. what do you mean ?
- Document, document and document (With better discussions on API design, code comments…).
Sure, everybody onto the wiki...
- Rolling releases with automatic updates? Ok, maybe it's too much for now!
Euh, yes too much for the moment... ;-)Yes, this is a lot of work but it won't be doing itself if we don't set the goal.Oh, now, I should get back to coding new features I'm being paid for…Good luck...Cheers,2014-02-24 11:59 GMT+01:00 Destailleur Laurent <address@hidden>:
I used a title that may hurt every developer. This is just to be sure everybody read my note ;-)Dolibarr is now a very large success among a very large number of users but also developers.During 3.5 beta and still now, we had received a lot of (too much ?) number of Push request for new feature, but nearly no code to fix bug.80% of request coming from external developers was new feature. Each request to add feature introduce around 2 bugs (this is an average value). This means to keep the bug ratio to same level we nee to spend 66% of code change (PR) to fix bug and 33% of code change (PR) to add new features.Because external submission are 80% of PR (Pull Request) to add new feature, we are far away of this ratio. The only one solution we had to not see the bug rate increase dangerously is to have the core team to work ONLY on bug fixes.This is what happened during all the 3.5 period (so several month). But this means also there is less time to validate "major" pull requests of really intersting new features.So some of you may see their pull request with status "pending" even several month after submitting them. Sorry for that. And after a long time, i will probably have to discard completely this pull request that can't be merged easily. Sorry 2.There is now so many people using Dolibarr, that keeping quality and keeping bug rates under control must be a priority, before adding new feature. But this does not mean we will slow down the increase f new feature. This just means that the conclusion is a strange paradox: if you want to help dolibarr project to increase the number of feature, make priority on bugs fix on old feature !(so bug rate will go down and if bug rate goes down, you will see new feature appears more quickly !)...Does this means Dolibarr popularity is growing too quickly ? May be, but this is a good news, isn't it ?
All this text to finally thanks all guys (core team and others) that helped me to fix bugs during the 3.5 beta ! and just after the release of 3.5. I hope they will understand it is a bug thanks !PS: Well 3.5.1 will be released very soon with result of all fixes...PPS: To find what are opened bugs, just create an account on doliforge.org and go onto this report:
And use the comments of tickets to ask advice on how you can fix a selected bug...
Laurent, Dolibarr main project leader------------------------------------------------------------------------------------Twitter: http://www.twitter.com/eldy10_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
--Raphaël DoursenaudDirecteur technique (CTO)
Technopole Hélioparc2 avenue du Président Pierre Angot64053 PAU CEDEX 9SARL GPC.solutions au capital de 7 500 € - R.C.S. PAU 528 995 921
_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
--Laurent Destailleur (alias Eldy)------------------------------------------------------------------------------------Social networks of my OpenSource projects:Dolibarr Google+: https://plus.google.com/+DolibarrOrg/Dolibarr Facebook: https://www.facebook.com/dolibarrDolibarr Twitter: http://www.twitter.com/dolibarrAWStats Google+: https://plus.google.com/+AWStatsOrgPoject/AWStats Facebook: https://www.facebook.com/awstats.orgAWStats Twitter: http://www.twitter.com/astats_project
_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
--Raphaël DoursenaudDirecteur technique (CTO)
Technopole Hélioparc2 avenue du Président Pierre Angot64053 PAU CEDEX 9SARL GPC.solutions au capital de 7 500 € - R.C.S. PAU 528 995 921
_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Laurent Destailleur (alias Eldy)
------------------------------------------------------------------------------------
Social networks of my OpenSource projects:
Dolibarr Google+: https://plus.google.com/+DolibarrOrg/
Dolibarr Facebook: https://www.facebook.com/dolibarr
Dolibarr Twitter: http://www.twitter.com/dolibarr
AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/
AWStats Facebook: https://www.facebook.com/awstats.org
AWStats Twitter: http://www.twitter.com/astats_project