Re: [Gnumed-devel] widget connecting

[Karsten Hilbert]

Next go:

1) patient input/search/modification, no relationship handling
2) keeping progress notes in simple SOAP structured text input
   fields (clin_note/clin_history/clin_physical rows)
3) per patient ASCII export of progress notes to text files for
   re-use constrained by date, encounter, episode, health issue
4) allowing third-party apps to connect to a GnuMed instance,
   lock it into a patient and release that lock later on
5) drug information browser if data is available locally
6) document archive if needed
7) simple ConfigRegistry plus complete default config data

> needed:
> - some place in CVS to store gnumed client data files, that is files
> containing data that can be read by the client (e.g. config files that are not
> subject to change and therefore should not go in ~/.gnumed/, or query 
> definition
> files for the DrugBrowser, or later maybe XML-definitions for wxPython GUI
> etc.). 
On deployed clients: /etc/gnumed/
In CVS: Just put them where it makes sense. Installation
should take care of putting them in the right place.

> I would not like to store these files on the backend because they are rather
> part of the client code than of the user data.
True.

> - a module that checks the current backend schema versions against versions
> needed by the client modules. My idea: load this module in gnumed.by and make
> any backend-related module (that is every module making backend connections)
> register its interests. Than check versions at some point and either just
> disable plugins or display a warning.
Interesting. This is the sort of infrastructure code that I am
referring to at times that makes a solid first release harder
than it looks. Do we need this for a first "release" ? But it
is certainly a good idea, I also like the implementation
proposal.

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