[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Comments on 0.2.......................

From: Ian Haywood
Subject: Re: [Gnumed-devel] Comments on 0.2.......................
Date: Tue, 20 Jun 2006 19:24:22 +1000
User-agent: Thunderbird (X11/20060516)

Karsten Hilbert wrote:
> On Mon, Jun 19, 2006 at 10:45:06AM +1000, Richard wrote:
>> There is something fundamentally wrong with the way you are approaching the 
>> writing of gnuMed and the paradigm of medical records you are attempting to 
>> implement.
> ...
>> I think your paradigm is wrong wrong wrong.

> So, Richard,
> 1) where does this approach go wrong fundamentally ?
This is not wrong insofar as it's meeting your requirements well.
Problem is, our requirements and priorities are very different,
We want to do pretty much the same thing in multiple slightly different
ways. One thing by itself is useless as we have no legacy platform to
integrate with: for us it's all or nothing.
I have found trying to do this with the gnumed framework (and trust me, I tried 
very complex, so complex it surpassed my abilities
as a programmer and so slow it surpassed my time-availability as an active 
so I confess I gave up.
A lot of the complexity are requirements that you, Karsten,
are very interested in, such as row-locking, concurrency etc.
These are in principle good,  but for me and Richard a big headache.
We don't need them: for most Aussie docs postgres alone is like science-fiction 
come to life,
most commercial apps don't let the same patient be open on multiple clients,
and most users think that's an inherent limitation of the computer and don't
Of course that's not a good thing, but we'd rather have a basic functional 
then go back and add these features (even if it means a rewrite)
> 2) where is the *result* as it is inefficient ?
look at the demographics code, personally I find it's a nightmare,
I mean no insult, the design errors I'm talking about are mostly mine.
[And the refusal to delete my old unused code is just infuriating.
we're using CVS for god's sake: we can always get it back!]

IMHO (for our purposes) we would need very aggressive abstraction in the 
and GUI layers,
to the point that you could write demographics with a wxGlade-generated module
and 20-30 lines of specific glue code. Is this even possible? I'm not sure,
I'm experimenting with some possibilities. I'm not positing this as an 
as the current framework is doing it's job well for you, but hopefully as a way 
out of
the proprietary nightmare here in AU, I'm frustrated as anyone this couldn't be 
part of gnumed-proper.

Ian Haywood

reply via email to

[Prev in Thread] Current Thread [Next in Thread]