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

[Carlos Moro]

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

Hi,

Ian Haywood wrote:

| This issue has been debated literally for years on this list,
| without any really satisfactory solutions. Many people have tried
| to think up ways of basically autogenerating middleware from the
| backend schema, (or generating both from a common base) However
| none seem to have the flexibility of our current "handmade"
| middleware, particular when it comes to wrapping complex SQL
| queries.

I don't think about  loosing our "handmade" control, but  evaluating
possible use of  some other free sofware solutions that could  be
helpful for us to concentrate efforts in specific Gnumed  business
logic  rather than in generic backend common tasks (db management,
async event handling, non client specific  performance issues...).
They might   fit into our current design and requeriments, and should
be relative trivial and painless to integrate:
~       -Distributed object access:
~             -Only most of business and pycommon classes would be
distributed. Client code woulnd't be specially affected. Only adecuate
cautions must be taken dealing with those objects. It would allow, eg.
a center with multiple really cheap workstations to interact with only
one dedicated server (not gui, just the distributed layer and sql
server)... Installation and configuration should be so easy for
client-only stations.  Server could be optimized...
~       -OR-mapping:
~             -Ideally and most currently, mainly  business classes
(eg. cClicalRecord)  are directly interacting with backend. Most of
queries aren't really complex. The complexity is really in our db
schema: views, procedures, triggers, etc... It would remain untouched.
OR-mapping tools just let your business classes interact with your
backend (that is "handmade" by us)  following rules you define
(mirroring db schema high level view) in some kind of configuration
file or module. They don't prevent you for direct SQL access whenever
needed... (desirably in few cases).


| Has been discussed. It commits everyone to Python on both client
| and server, which is felt to be unacceptable.


~From the point of view of medium term requirements it's not
unacceptable. It could be seen just a natural step forward.  It
wouldn't be suitable for providing distributed objects to apps in
other languages (which isn't a requeriment at this moment...).
Moreover comparing with each client having its own business layer
integrated.

And if requirements grew, the impact of moving to another kind of
distributed server  wouldn't be so painful: clients were yet used to
distributed access, ideally just the local interfaces retrieval would
change... But that's out of current scope...

| Unfortunately these basic design decisions have been made -- we
| need a really good reason to start again from scratch!

I  didn't pretend to reopen any flame or closed thread O:)  . Just
found some projects that seem  well designed  and thought, 'Would be
useful for us? What would Gnumed fellows think about it?' So i
commented it ;) .

BTW i really like current way of Gnumed development process and i
don't have any doubts we're (with Gnumed current design and
implementation line) in the right way and that any kind of
server-backend and client-frontend requeriments will be perfectly
addressed :)

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

iD8DBQFBJ3BL5BCD+/pQ4WIRAjlOAJ93Ni+4n0IICKycpXxrW2nLgddUIQCgrh/L
0CcM+7XgPy0PoBABcQsdxjg=
=+zhO
-----END PGP SIGNATURE-----