>> We are in "unlucky" situation that there is no GUI, but hey, that is
>> how things are in Java.
>
> GUI is a part of documentation.
> 'Self documenting' is considered one of its main benefit.
>
> So if you do not have GUI, you either pay more attention to written
> docs, or have worse docs.

So far there were no such issues in this group. At least I do not
remember them.

> // Error messages and prohibiting certain scenarious like
> non-specified charset can also be considered an ultimate sharp form
> of
> documentation. If GUI enforces selecting charset one or another, it's
> counterpart might be denial to connect without explicitly set
> charset.

Agree. But I am not ready to make this change in 2.2.0

> You claimed that changing default behavior of Jaybird would break
> legacy Delphi applications.
> I told you - it would not because GUI docuemntion.

Sorry, you cannot guarantee this. So we have to look for a better
solution.

> That is not about comparing, that is only question if concerns about
> legacy Delphi application valid reason to stick with current Jaybird
> defaults.
>
> You claimed JB changes would break most Delphi apps, using the same
> DB. I told they would not.

No, I just made a case where such change will lead to corrupted DB. I
did not say that it will break most Delphi apps, that is your
interpretation. But since I cannot enforce correct behavior, I will not
change one dangerous behavior to another one.

>> Nope, but do not make the JDBC driver developers responsible for bad
>> design decisions made long time ago.
>
> When you told "Trackstudio developers are guilty" it is not a
> "decisions made long ago".
> And what worse, it would lead to FB alienation.
>
> I was suggested against FB.
> I was told "there are always some rundom unexpected bugs in FB. We
> only support it because of few clients requiring. Don;'t use it if
> you
> do not want troubles"
>
> And claiming "Developers and HelpDeskers who did not read Appendix D
> or did not understood all the implications are to carry the blame"
> would not change that image of FB.

Sure. But your suggestions are dangerous as well, in other way, but
still dangerous. So, a better approach should be found.

As to the Firebird's image - we had a lot of different images, between
"the best DB" and "the worst DB". Same applies to MySQL and PostgreSQL.
Firebird has its user base, Java being only 6% of them, .NET a bit more,
the rest are Delphi people. Web is yet another story - we can have
lengthy discussions about what is right and what is wrong...

> Either
> * claim "we do not care about web applications. FB is not for them.
> We agree with developers discouraging use of FB in that realm."

Wrong.

> * or think why those developers fall into unexpected tarpits and
> what can be changed to make newb's attempts at FB easy and smooth.

That's what we did. But do not expect that every change will be fixed
in minutes and new release will come out. If that is not acceptable to
you, then, unfortunately, FB is not for you.

> The claims like "those developers did bad" would keep FB considered
> unpredictable and/or unreliable.

No. The most easy way is to send an email to those developers and
advice them to perform the change.

Roman