[Top][All Lists]

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

Re: [Gnumed-devel] gnumed architecture

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] gnumed architecture
Date: Wed, 4 Jun 2003 15:24:45 +0200
User-agent: Mutt/

> 1.) SQLRelay can replicate and load balance PostgreSQL servers = free 
> scalable solution
Thanks for supporting my point. At one point we decided
against using SQLRelay because it does not support (at least I
can't find it) backend notifications in PostgreSQL. The point
being that SQLRelay requires client changes (although it does
come DB-API 2 conformant) and thus cannot just be swapped
in/out at will depending on target site installation size.
Hence the decision is for/against the additional overhead
hence considerations for larger installations conflict with
considerations for smaller installations.

> 3.) Blobs are a service in gnumed, hence no problem with them anyway
They are not currently. We are considering to make them into
one running on, say, XML-RPC. The requirements for a GP office
storing a few thousand scans are different from a
CT/CathLab/MRI/what-not hospital imaging department. In my GP
office one (I) can often live with the BLOBs server being down
for a day or so. Not so in high-volume hospital settings where
one will deploy live failover servers which aren't
cost-effective for a GP office. In a GP office we can probably
make do with the relatively inefficient (for binary data
anyways) XML-RPC interface while that is not appropriate in an
digital X-Ray department of a hospital where DICOM-on-the-wire
may be a necessity.

Certainly, I don't have much experience with the innards of a
HIS but I just cannot see how the two models are one.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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