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.demailto: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.orgmailto: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