Hi there, Thanks for the comment and suggestion of a more specific name : What about « Gtk2::Ex::DbLinker » ?
I understand Daniel’s concerns but I would assure him that my lack of response was not because I didn’t care. I was surprised by his cautious answer and had not realized the evolution of his modules compares to those I got from CPAN. Maybe we will unfork in some time ? maybe both modules will find their users and will address different needs. François From: gtk-perl-list [mailto:gtk-perl-list-boun...@gnome.org] On Behalf Of Daniel Kasak Sent: jeudi, 15. mai 2014 06:00 To: gtk-perl mailing list Subject: Re: RFC: Gtk2::Ex::Linker 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 On Sun, May 11, 2014 at 8:44 AM, Torsten Schoenfeld <kaffeeti...@gmx.de<mailto:kaffeeti...@gmx.de>> wrote: On 09.04.2014 15:25, RAPPAZ Francois wrote: > Gtk2::Ex::Linker Looks interesting, thanks for sharing! It is a little unfortunate that you could not agree with Daniel on a common way forward, but that happens. I do think that you should try to find a more specific name for your module. "Linker" seems too generic; maybe Gtk2::Ex::RdbLinker? _______________________________________________ gtk-perl-list mailing list gtk-perl-list@gnome.org<mailto:gtk-perl-list@gnome.org> https://mail.gnome.org/mailman/listinfo/gtk-perl-list
_______________________________________________ gtk-perl-list mailing list gtk-perl-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-perl-list
