This conversation should be really be taking place in a dark bar, with
sticky tables and lots of beer. I find that usually makes it easier to
solve the world's problems. :)
>
> GPRE is a utility which has created for very specific needs, which time
> has passed by.
>
I tend to disagree but that is my particular point of view I suppose.
GPRE has certain benefits. It is less complicated than programming
to the API. It is slightly more efficient since the SQL is
precompiled. It is the only thing that works well for Cobol.
>
> Finally, GPRE works. It didn't/doesn't support the latest engine, but
> in a support legacy app situation, it doesn't need to. Nothing says
> that Firebird needs to concern with supporting everything back to day
> one.
It is more accurate to say that GPRE works for C and C++. It doesn't
work nearly so well for the other languages that it claims to support.
It works for RM/Cobol because I made it work. The Ansi Cobol and VMS
Cobol (talk about something that time has passed by) interface is
still seriously broken but I have no reason to mess with it and no one
else is complaining.
>
> It don't think it is fair to hold Firebird responsible for the fact that
> your stuck with the (unenviable) task of supporting an ancient
> language/environment. For which, by the way, no project member has
> experience with.
I'm not holding Firebird responsible for supporting my app, just the
tool that I need to make it work. Either GPRE is part of the Firebird
release or it's not. I've actually invested a lot of time in making
GPRE do what it claims to do and I guess, ultimately, I have no
problem continuing to do so if that is what it takes.
Originally I started out looking for a better way to make GPRE more
consistent with the rest of Firebird but the conversation got a bit
off topic. My fault I suppose.
BTW Cobol may be ancient but that doesn't mean it is dead. There is a
lot of Cobol out there and new applications are being written in Cobol
every day. Cobol apps are also being ported from mainframes down to
smaller systems every day and if Firebird provides decent Cobol
support it might have a shot at picking up some of that action.
If the project is lacking Cobol expertise, perhaps I need to become a
member, but that is not really a discussion for this list.
>
> But at the same time, the reality is that your in a place because your
> put yourself there, Firebird didn't put you there.
I don't blame Firebird for the fact that I have way too much Cobol to
maintain, but GPRE is a part of Firebird, it claims to support Cobol
(and it does now) and that factored into our decision to use it. I
would like to see it continue to be maintained and like anyone else,
if I can get someone else to do it, so much the better. Tinkering
with GPRE doesn't pay the bills but as I said before, if that's what
it takes I'll have to do it.
Overall the upsides to using Firebird far outweigh the downsides.