gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] Conference Report


From: Ian Haywood
Subject: [Gnumed-devel] Conference Report
Date: Tue, 12 Aug 2003 18:26:54 +1000

I  intended  to do this on  Sunday but a combination of technical
failures and a truly demonic roster for the surgical job have led
to it being late. Note that this is a synthesis of a number of separate
conversations with various people over the 2 days.

We agreed at the conference that gnumed development had proceeded a lot
slower than we had hoped, and that
it was important to expidite client development. We agreed lack of
proper design and a clear development plan were
largely responsible for this situation.
[It is important to note a lot of "infrastructure" work has taken place.
mostly by Karsten]

<AU> The point was also raised that the major competitor Medical
Director is switching to windows SQL in the next year or so, a
good time to enter the market.</AU>

Horst announced that he would commence work on a "quick" client, using
Python/Tk, and monolithic postgres server as a
private project to get something working, this takes the pressure of us
a little, but it is universially agreed that the current gnumed client
is
the definitive client and work will continue on it.

The current client was criticised on a number of points:
    - lack of borderless widgets [as an aside, this is probably a
limitation of the underlying GTK library, a switch to Qt is the only
real solution here]
    - lack of good design tools
    - hacky double plugin structure
    - hacky UI modules [no offence Richard]
    - lack of overall design consistency ("Richard space" and "Karsten
space")

Solving any of these implies a UI code rewrite, even if we stick with
wxPython.

The Plan:

To construct a Python/Qt client as follows:

1/ Richard will write plain English functional specs, using his client
as a guide [1 month]
1a/ Specs for clinical notes viewer are added

2/ UML object design from said specs devised. A skills shortage is this
area was identified,
Tim Churches has indicated he knows some people who may be able to help
[1 day workshop + further month]

3/ actual coding based on above object model [timeline unspecified]
Need to pick clincial coding system at this point.

Barring some massive advance with drugref, it is agreed that MIMS is the
drug database in AU.

It is agreed that work on the backend should continue as is.

Architectural concerns: [IMHO, this is where much if the problem lies,
it
is difficult to do much work without firm foundations]

Choices discussed:
1/ Status quo: wxPython client, pluggable with 2 plugin systems,
communicating with multiple PostgreSQL servers via middleware
(which is not truly GUI-independent)
Pros: what we've already got, design stability
Cons: see above, IMHO substantial GUI code rewrite is required anyway.

2/ Qt using Qt's own database objects and data-aware widgets
Pros: easy, cool, simplifies dependencies
Cons:
- fixed to Qt now,
- will need a middleware layer anyway for some things,
- complete rewrite of everything except SQL code.

3/ Qt using Karsten's business objects,
Pros:
- portable, can retain existing wxPython codebase (??? but who will
maintain it ????), plus future Web, PDA, etc.
- retains important features already implemented in middleware
(updating, read/write connection separation,
multiple servers)
[NB Richard's client only uses 2-3 actual widget types (part of it's
advantage) so it is easy to add
data-awareness via the middleware layer]
- My favourite ;-)

Cons:
- GUI rewrite
- need to remove dependence on wxEvents, gmDispatcher throughout code
- licence issues as noted
- slower to develop than 2

4/ 3/ with communication via XML-RPC
Pros:
    - uses XML buzzword
    - sharing services with OSCAR, etc.
    - simplified client dependencies.
    - client now very small and portable, can presumably port  Syan's
Java client to this API at some point.
Cons:
    - middleware API rewrite also (no passing objects, no fancy Python
s**t with mapping
dictionaries to functions)

Client design:

Horst has proposed (and offered to write) a unified plugin syatem for
Qt, which is much more flexible
than the existing one, with resizable windows.


Ian Haywood

[NB whatever the header of this e-mail says, my personal e-mail is
address@hidden so long
as the GNU mailservrs are down, which looks like a while....]







reply via email to

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