Re: RFC: Gtk2::Ex::Linker
- From: Daniel Kasak <d j kasak dk gmail com>
- To: gtk-perl mailing list <gtk-perl-list gnome org>
- Subject: Re: RFC: Gtk2::Ex::Linker
- Date: Thu, 15 May 2014 14:00:08 +1000
OK I guess I should comment on why this was forked from my work ...
I asked François a couple of times to comment on some basic things like:
- compatibility with existing supported databases
- use cases
- advantages in this approach ( a major piece of work )
- features I'd lose
... and didn't get an answer, or the answer felt like "don't know, don't care". François sent me a demo application that didn't work at all. I hacked for a couple of hours, and still couldn't get anywhere. It pulled in LOTS and LOTS of dependencies that is never a good idea for compatibility - in particular if you have clients on Windows. More broadly, using an abstraction layer like Rose::DB seemed to add considerable complexity ( and dependencies ), while making further development and debugging much more difficult. Rose::DB only supports a handful of databases, whereas I have a bunch of oddball databases with broken drivers to support.
As François' work was forked from a VERY old version of my code, which I'd put another couple of hundred ( possibly thousands ) of hours of work into, it all seemed like a lot of work for absolutely no benefit.
I have a number of clients using my code in a production environment, and I have zero scope to tell them "yeah there are a whole heap of things broken because some guy asked me to accept a massive patch that took my code back by 5 years and targeted some ORM thing".
If François had contacted me early on and told me of his intentions, and better described some things like key benefits ( of which I currently know NONE ), I would most likely have worked on this with him. Not getting that basic communication at the START of the project is really not a good sign of things to come down the track.
As things stand now, I've already done 'final' releases of Gtk2 versions, and I'm working on Gtk3 ports of both form and datasheet classes, on top of all the work I'd done over the past couple of years ( Oracle, Teradata, Netezza support, sequence support, multi-column primary key support, and stacks of bug fixes ). François is free to have another attempt at porting his work to a current version of my code, while addressing the above issues, at which point I'd be much more likely to undertake the MASSIVE testing & fixing exercise that would follow.
Dan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]