On Wed, 23 Mar 2005 08:33:58 +0100, Kjell Rilbe wrote:

>
>Fabricio Araujo wrote:
>
>> Internacionalization
>> ====================
>> If to attend you it will cost me anything that can
>> affect end users, is not OK.
>
>OK, I might agree, but the thing is that keeping the limitations we're
>discussing here does cost *me* something. So, you're saying option B is
>not ok because it costs you something compared to option A, but the fact
>that option A costs someone else something compared to option B doesn't
>matter. Excuse me, but that's selfish.

Keep the limitation until you can do it in a way that not disrupt
existing
applications. ASCII char/varchar fields must continue work as always,
the
same way as performance of server under normal load - not to talk on
relia-
bility.
No documented behavior must be broken unless all alternatives are
dismissed.

>> If would cost nothing on
>> performance, no code would break, I will continue with simple ASCII
>> fields working like always, without increasing the
>> network traffic (which FB is not very economic in it's
>> wire protocol), or any of that things, so GO FOR IT.
>
>Short term problems. In the long run, the problems you're suggesting
>won't exist or will be so small compared to everything else that the
>just don't matter, due to more powerful computers, higher bandwidths,
>etc. In short: progress.

Progress costs money. Brazil is not Sweden. Many customers of FB
developers
still have 10MBit networks and network traffic is, yes, a issue.
Some even cannot spare a computer to be a db server, sharing it with
printers, file shares, etc.
Performance penalties reduces scalability (how many users can be server
with same combination of hardware/software).
So much of time we have to live with that limitations.

>> Case sensitive identifiers
>> ==========================
>> *Forcing case* is not a good thing.
>
>I just don't agree and I have repeatedly given imo strong arguments for
>my position. I give up.

If for a case mistake a entire system could disrupt or
behave wrongly, I can not agree with you at all. So,
the system is not reliable and can be affected for case
mistake - a kind of the error that is easy to make and
very difficult to see and correct.
It's a nightmare.

Here on job, people complain that I'm almost artistic
with style requirements to writing stored procedures.
I become really piss off with wrong indentation. Not to
tell mixed case as in this example: @parm_Id_Usuario
I have hundreds of stored procedures, if in one them
I put (for example) ID_Usuario instead of Id_Usuario I expect
to it to continue working as usual. Case insensitiveness
is a good thing as it increase the level of robustness
of the system.

But require that I remeber the case of every identifier
of db just to got the job done - ah excuse me but are
mad.