Re: [Gnumed-devel] Conference Report

[richard terry]

Well put Ian, much better than my lobsided pathetic previous posting on choice 
of GUI which was probably more a product of my frustration than cool logic.

Team should probably ignore my posting and those able to make decisions on the 
basis of their technical knowledge, on what Ian has said below, make the 
choice and I'll go along with whatever is made. But please, make a choice!

In the meantime I will start on the gui/functional specs.

Richard

On Tue, 12 Aug 2003 06:26 pm, Ian Haywood wrote:
> 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....]
>
>
>
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnumed-devel