gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] roadmap


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] roadmap
Date: Mon, 28 Jul 2003 20:56:01 +0200
User-agent: Mutt/1.3.22.1i

> > Eventually, you would see that more and more code (whole classes) can
    ^^^^^^^^^^
This is the crucial word here.

> > be defined in XML and Python is only needed for the parser. That is
> > what I am currently working on, in Java. As everything goes more and
> > more XML, I get independent from Java or whatever parser/language is
> > below. My aim is pure C, one day. Finally, GNUmed, OIO, OpenEHR,
> > Res Medicinae, ... could synchronize their XML models (in some years).
> > 
> I take back my comments about gnumed lacking a design phase. The problem is
> that we never left it, constantly re-designing and re-re-designing, while our 
> prospective beta-testers
> become increasing despondent.
Ian, don't worry :-)  Christian's comment is not a design
attempt but just a loose rambling of thought. It does not
influence current design decisions much. It does certainly not
affect the roadmap especially since it does not in any way
even discuss the roadmap.

Sorry for being a jerk but I am trying to be a constructive,
pragmatist jerk.

> Don't get me wrong, these ideas have merit, but the purpose of the roadmap is 
> exclusionary 
> rather than inclusionary:
Excellent ! I see that you have the same idea on this as I do.
I should certainly prefer to *take away* things from the
roadmap rather than adding them.

> how can we get directly from *what we already have* to a minimal version,
minimal *useful* version IMHO
 
> which can then serve as base for XML adventures.
I shall burn in hell if I suggested any XML adventures. I
merely offered this as one way for defining the *forms* IF
someone thinks of starting the "forms engine". And I even
backed down from that if we restrict ourselves to
referral/prescription, initially...

> Perhaps we should consider odd-even versioning like the Linux kernel: evens 
> are feature-frozen, it aims to
> to get it "out the door", odds are the cutting edge for trying out new 
> features.
Perhaps actually worth a try.

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




reply via email to

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