[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] gnumed-mini
From: |
Karsten Hilbert |
Subject: |
[Gnumed-devel] gnumed-mini |
Date: |
Thu, 15 Sep 2005 18:58:20 +0200 |
User-agent: |
Mutt/1.5.9i |
> We've been spending the better part of the last 4 years to
> do the following so welcome back to Ground Zero:
>
> > So I started to rewrite the system, this time I wanted to do it properly,
> > and
> > using a non-proprietary backend schema.
> ...
> > I want to clean that up and document it properly before I bother people
> > with
> > it.
>
> > In principle, the architecture looks like that:
> >
> > a) every database concept (like "a patient", "a doctor", "an address" etc.)
> > is
> > wrapped into a gmdbXXX class with standardized high level accessor methods.
> > They all inherit common traits from a gmdbObject ancestor including a very
> > simple and crude caching mechanism. There should be no SQL queries at all
> > in
> > the GUI code
> Hm, this sounds suspiciously like gnumed/client/business/*.py
>
> I have to admit I haven't yet been able to see through the
> caching mechanism. I am sure keen on learning whether it
> provides benefits over what we use in GNUmed.
>
> > b) every possibly self-contained functionality (e.g. "prescribing",
> > "appointment booking") exists as an independent module which can be run
> > either standalone or as a plugin within the gnumed framework
> While nice and having been tried I have found it to be hard
> to maintain. Likely our GNUmed code isn't clean enough yet.
> Once you get to a certain complexity of functionality there
> are assumptions in the code that are met by the framework
> which isn't available when running standalone ...
>
> > c) all such independent modules ( regardless whether gui or not)
> > communicate
> > with each other exclusively via the central messaging hub (dispatcher)
> Likely we have taken a few corners here that prevent us from
> running plugins standalone.
>
> > d) as a rule, GUI components are designed with wxGlade. The generated GUI
> > code
> > is never modified manually, but a wxXXX module inherits from the generated
> > wxglXXX module.
> How does this allow for creating widgets from non-wx-Core
> GUI classes ? Say I wrote a dedicated progress note
> notebook, how can I use it in wxGlade ?
>
> > f) Not only for simplicity, but also for speed reason, the backend schema
> > is
> > not always normalized.
> Does it properly support clinical encounters and episodes
> of care ?
>
> > At times, where it would yield a substantial
> > performance gain, foreign keys *may* be the data itself
> "would" or "does" as in "tested" ? I doubt it'll make much of
> a difference in most cases. Or so the PostgreSQL people
> attest to.
>
> > g) the backend schema is versioned. Modules check what backend version they
> > need. The backend is updatable incrementally - after the first full version
> > number, only "update" schema sql snippets will be generated, allowing
> > update
> > of a running system without anybody having to log out first
> Same as GNUmed.
>
> > h) installation should be running "gnumed.sh" and "python setup.py install"
> > and nothing else, no hoops to jump through for the end user. This requires
> > an
> > administrator running gnumed.sh as somebody who has the right of creating
> > new
> > postgres databases and users
> Yup, that is doable with GNUmed as it exists now. Do you
> intend to store program bitmaps (icons) in the database
> generated from python encoded inline data ? Or else how do
> you intend to make "python setup.py install" install bitmaps,
> docs etc in a client system ?
>
> Trust me, been there, done that.
>
> Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
- [Gnumed-devel] gnumed-mini,
Karsten Hilbert <=