Re: [Gnumed-devel] thanks re mimencode

[Horst Herb]

On Fri, 10 May 2002 22:48, syan tan wrote:

> so is java ever likely to become a language where developers that stay
> with gnu license , are going to need to pay fees? python is getting a
> little commercial recently , so how does the freedom differ?

Java was never a free language, and explicitly designed to promote 
proprietary code. What is this about Python going commercial? Python is 
licensed GPL - thus it will always remain free.

> I suppose the more heavily reliant one becomes on the ever expanding
> java libraries, the more likely sun is going to slap a not for
> distribution without paying homage etc...

That and the undemocratic process of dictating what "complies" with Java 
standards has put me off completely of Java. and, I think it is a quite 
unreadable language, where you immediately get lost w/o class browsers.

> implementations for the gmPerson... stuff,  I noticed I'm likely to be
> completely binding the client ui code with the names of fields and
> tables in the postgres server table conglomeration. On the other hand,

This is why we suggested there be one function data->interface and one 
function interface->data instead of direct mapping of singular widgets to 
data. We want to keep the program logic a bit more independend of the 
choice of interface.

Ask yourself: "what do I want to achieve with this dialogue?" The answer 
most often is display, and/or edit, and/or add data. So write a library 
that allows you to do exactly this with the data you refer to in the most 
comfortable and straightforward way. Once it works, bind it to the user 
interface of your choice, because there will be many ways to go to Rome. 
Users have different preferences regarding user interfaces, and what suit 
the "majority", might not suit you or me.

>   Is three tier unnecesary for the scope of gnumed ? Or is the
> availability of views and triggers in sql sufficient as the middle tier?

I had implemented a middle tier in C++. The client connected via TCP/IP 
(SSL) to it, and it connected to the backend via TCP/IP (SSL). However, it 
turned out to be a performance bottleneck (instead of the opposite) and 
had no advantages whatsoever regarding security as it always could be 
bypassed some way or another. The main feature (replication) was thus not 
reliable, and all the effort of parsing teh query tree twice (once on teh 
middle tier, once on the backend) was futile.

Horst