Re: [Gnumed-devel] thanks re mimencode

[syan tan]

On Fri, 2002-05-10 at 21:56, Horst Herb wrote:
> On Fri, 10 May 2002 21:00, syan tan wrote:
> 
> > looks a lot cleaner and more attractive then what wxpython newbies are
> > getting at the moment, but can vb be made cross platform? Anyone know of
> > a unix version of vb ( e.g. like antiword for word docs)?
> 
> Design can be done with whatever tool is preferred, but implementation will 
> not happen within the gnumed project itself with non portable non free 
> tools.
> 
> > Otherwise, why not develop the ui in VB , but connect to postgres
> 
> For the above reason. I woud not have started the gnumed project in the 
> firat place if I would not have believed that a proprietary platform will 
> never be adequate for medical needs.
> 
> > SOAP to call server functions as function calls. Maybe we can get trendy
> > and have a gnumed Web Service  ;)
> 
> There will be a gnumed web client, but it has no priority at present 
> (unless somebody steps in and just starts doing it, which would be nice)
> 
> >   The idea is that the developer who has the most developed ideas of UI
> > begins rapid development in the ui he is familiar with, and the rest
> > follow with adaptions in cross platform formats ( wxpython, java ).
> 
> That's what we are doing. Richard paints his stuff with VB (though I think 
> that he could at least do it with glade or QT designer, tahn it would be 
> good for more than just aking snapshots and helping the implementers to 
> get an idea what it should look like.
> 
> Horst
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnumed-devel

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

Also, I noticed that the three tier idea was discussed on gnumed years
ago, and even promoted at one stage ; whilst doing  quickie
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,
if a rpc (remote procedure call) like protocol were to be used, the
client ui code would be bound to the rpc interface definitions of the
rpc service programmers,
but at least the sql stuff could change behind the scenes, and the ui
code wouldn't have to change much. On the other hand, if prototyping
shows the interface definitions are inadequate, missing parameters,
missing functions, then the client would change, and even if just the
sql changes, the rpc service writer would have to change the database
access code. Presumably, if a good interface is designed, then the
change at the rpc service writer implementation code would save a lot of
changes in multiple places in the client ui code, because of good
factoring of the functions. But then again, it may mean there is just
another layer to debug...
  Is three tier unnecesary for the scope of gnumed ? Or is the
availability of views and triggers in sql sufficient as the middle tier?