> > Unexperienced ones would look "that field... huh? what is it meant to
> > be, especially for non-English countries ?" and look docs.
> >
> > Also the default might be "-- set the value to enable OK button --"


> 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.

// 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.

> >> C'mon, the issue you had is caused by the developers of the system
> >> you
> >> wanted to install.
> >
> > Formalist approach.
>
> No, only trying to get both cases to one common denominator.

That is not common.

You discard GUI which is part of documentation, especially important for newbs.

Okay, if you discard docs - discard them all.



And what point in comparisons ?

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

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.

That was not comparison Delphi vs Java.

> No. I did not say that.

But you discarded Delphi documentation, targeted at newbs, as if it not existing. If to compare Delphi and Java ways (why?) then not this way.

> >> One can expect that they know what they are doing.
> >
> > You mean drop Firebird support to avoid learning its scarcely
> > documented gotchas ?
>
> 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.

> Stop ranting. You asked the question,

that rather lengthy discussion touches several questions.

> that situation with defaulting to NONE is not ok,

that was not the only question here.

To start with, the question was about absolutely different application (namely XWiki). That question was not answered (or was answered "maybe later")

Track Studio was only an example of curiously strange crasher, when JB 2.2.0beta breaks HSQLDB connectivity. That was also answered "maybe would have a look when have time".

And the question "How to create FB DB in TrackStudio?" was not even secondary! Even not secondary. That particular question was closed on Thursday.

But it sparked discussion of what should be general rules and policies. The discussion lengthy, maybe unwanted, but separate from the question above.

> Oh man... what do you expect from Firebird team then?

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."
* or think why those developers fall into unexpected tarpits and what can be changed to make newb's attempts at FB easy and smooth.

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

And when i try to express what i consider wrong in policies and documentation, it is because i want www developers ultimately start treating FB the same "plug and forget" kind of workhorse like Delphi developers did for years. Not the quirk of those who can not master real servers.