[Gnumed-devel] Thinking about a Gnumed middleware... maybe Gnumed2

[Carlos Moro]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

~    Hi all,

~    Along many list threads it arised we're worried/interested/needed
of some kind of  rich featured, not overkilling to use/deploy, and
good performance middleware layer.  The project is really going ahead
(congratulations to every one!!) and its requeriments will surely grow
with not far away real use. In that time, will find extra difficulties
to expand and scale Gnumed, mainly not by our backend model (it's more
than good, I believe) nor by our GUI client(s) (have you recently ran
it under gtk2? It's more delightful each day!!). I imagine different
kinds of use: from an economic poor medical box in a small town
anywhere (maybe running 1 linux host and even sharing X.25 radio
connection to a bigger centre) to small/medium health centers  with
tens of clients running concurrently...

~    It's soon at the moment (uh!, but really nice to dream...) but we
could begin to think about some design/arquitecture that would Gnumed
evolve and scale well. I think it will involve clearly decoupling
client, middle and backed layers. I'm more used to effective
alternatives in Java (many times overused and missunderstood) but,
looking for Python, i've found two of them that would allow to
accomplish at least two major (i believe) requeriments:

~       -Distributed Object Technology: it must be free, fast, easy to
use and tested in real complex enough projects. It must be suitable
for use in the two scenarios i commentted before... Also development
process would be simplified, allowing some developers to work safely
in middleware middleware without breaking client code, based in
interface contract...
~             -Pyro (http://pyro.sourceforge.net/index.html) seems a
mature enough option... It also provides a Notification server
(without the need of that beast.... of CORBA  ;) ,
http://pyro.sourceforge.net/manual/6-eventserver.html )

~       -Object Relational Mapping: we're facing serious aims in object
fetching/creating/updating. Conceptual, performance and mainteinance
matters arise... Our backend model if really nice, just we must owe an
effective and easy for us way to deal with objects and relational
persistency... we could always contribute to the ORM code if we had
any not implemented requeriments rather than build the core engine...
~             -Modeling Object-Relational Bridge
(http://modeling.sourceforge.net/main.html) have advances features.
Also it seems to manage properly memory footprints...
(http://modeling.sourceforge.net/UserGuide/ec-fetch-raw-rows.html).
Also provides another notification api
(http://modeling.sourceforge.net/API/Notification-API/index.html)

~    I repeat i dont't know well Python 'enterprise' world. Those are
just a couple of proposals/ideas that maybe we could test and
evaluate... sure there would be other alternatives...


Best regards,
Carlos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBJzmy5BCD+/pQ4WIRAmZaAJ4kfyQI8PMuEbQO6KvUpgjbHPT4fwCdEMSY
giwBmHIHwDnqTDVsFXIN/Xw=
=el0K
-----END PGP SIGNATURE-----