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

[Karsten Hilbert]

On Tue, Jun 20, 2006 at 07:24:22PM +1000, Ian Haywood wrote:

> > 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 tend to forget that point but it's entirely valid IMO.

> I have found trying to do this with the gnumed framework (and trust me, I 
> tried hard)
> very complex, so complex it surpassed my abilities
> as a programmer
Same thing with me trying to implement Richard's design: It
surpassed my ability as an efficient programmer. I have
always said so.

> 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.
I understand that.

> We don't need them:
That is a misconception. However, it may very well be
sufficient to put a wrapper around them which handles them
in an invisible, default way such that you don't have to
worry about them. As if they were not there. But they are
still handled. Just that you don't have any control over
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,
Well, simply *using* PostgreSQL as the backend DOES NOT
ALLOW ONE TO SAFELY DO THAT. It needs to be used *right*.
Doing it right is, yes, complex. If we can't handle that
complexity we better not try. I won't be involved in
producing crap.

> Of course that's not a good thing, but we'd rather have a basic functional 
> client,
> then go back and add these features (even if it means a rewrite)
Well, the current database schema does not prevent you from
ignoring row locking and concurrency. You could *just write*
a client ignoring those issues and still store data in the
same schema. The rub of it is not the "ignoring" part but
rather the "just write" part.

> > 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!]

Look at client/gmDemographicsWidgets.py again :-)

Where else do you think we should delete code ?

> IMHO (for our purposes) we would need very aggressive abstraction in the 
> business
> 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 should think so.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346