Re: [Gnumed-devel] keep testing, or add to main source?

[Ian Haywood]

On Wed, Oct 08, 2003 at 11:14:52PM +1000, syan tan wrote:
> Ian Haywood wrote:
> >This is the biggie. Unfortunately Syan has ploughed ahead with out using 
> >the considerable body of database infrastructure already developed, 
> >without giving
> >a  clear reason.
> >
> Least resistance path I suppose. I haven't tried to read up the business 
> objects yet.

Please do ;-)
 
> gmEditArea3 is not hard to do because it has no API to program to: it 
> would be nice to discuss the formats going
> to be used (  other drug database APIs (is there a standard?) 
Absolutely not. 
> api,  LDAP  and  a simple example of how
> demographic data is going to be stored on it, 
LDAP schemas are generally standardised

> and how is a messaging 
> API going to fit in with all this? ( Is it Jabber transport, and
> HL7 v2.x  ?)  
All post-1.0 stuff. presumably business objects can be written to
wrap Jabber/GnuPG etc.

>Can one leave security APIs out, and then worry about 
> them 
> later when things are working?
Certainly.

> Is the demographic business objects going to be one interface and 
> different implementations ? 
Yes. 

> So what's the common interface,
Please read gmDemographics.py I would be interested in your comments,
particularly as it would be good to standardise the interface to 
make it easy to tie to GUI.

> and what about making easy enough to generate a prototype sql access to 
> arbitrary structured  tables , so development
> isn't stalled on tackling issues such as learning above APIs.
Not sure I understand.
 
> get sql contacts working first?  Doesn't openLDAP have a SQL api? if so 
> , what is the standard
> schema for the SQL api , then can model the test SQL contacts schema on 
> it? (? oversimplified?)
No, LDAP schemas are standard (unlike SQL), this the power of LDAP (so 
Microsoft Outlook can talk to our LDAP servers, for example) Similarly 
an LDAP server set up by Governemnt etc. who don't know/care about 
gnumed, we can still interface to their servers.
 
> Is there any point in trying to get around the boring part?  What about 
> writing a interoperability tool to convert arbitrary schemas from
> one form to another? (e.g. from the auto-generated schema, to whatever 
> schema is easiest to translate or best to store)
The business objects are not a schema, they do diiferent things.
I don't see how you could ever auto-translate from one to other.
 
> Then someone should define the interface for the dbobjects , and some 
> work can be done for the simplest implementations ( custom arbitrary sql 
This is what I am discussing.  
I agree it would be nice to auto-generate everything, but to be honest I 
find it just gets in the way of doing what has to be done.

> But it already works with just dumb text matching for those 2 cases ( 
> except when matching indicated drugs, but then a  narrowing indication 
> table could be used)
Yes, but the example doesn't have 1% of the functionality required!
 
> please elaborate this concept (in an example); why ?
This Context object wouldn't work, forget it ;-)
But we still need a way of match providers being aware of the
values of the other phrasewheels as this determines their matching.

For example, if a patient has gout, and the user types "a", the 
phrasewheel should return "allopurinol" as its first guess, but
if the disease is depression, the guess should be, say,  "amitryptaline"

> Why gmDispatcher and not just listctrls bound to editareas? Why the 
> indirection?
Sorry I don't understand the connection between listctrls and 
gmDispatcher.
 
Ian haywood
-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

pgpuG3GzZ4W6q.pgp
Description: PGP signature