Re: [Gnumed-devel] A question re demographics

[Horst Herb]

On Mon, 19 Jul 2004 19:53, Ian Haywood wrote:
> > > Patient picture, well, let me work on that, shouldn't take too long.
> >
> > There's a v_latest_mugshot on the backend. Also, I believe
> > there's code somewhere (gmDocFolder or so ?) to fetch it. Be
> > aware, though, that fetching the patient picture is a big time
> > sink (hence that pesky "needs to be implemented async" message
> > on the console :-)
>
> It would be nice IMHO to implement a general solution in gmDispatcher
> That is, an option in gmDispatcher.connect () to register as a "async"
> handler which is called in a background worker thread after the foreground
> handlers have finished.

the callback registered in gmDispatcher should be designed in a way that it 
always return quickly!
That is, it is the responsibility of the registering widget that the 
registered callback will not delay program flow.

Downloading large binaries is tricky - since it involves a single Python call, 
and with Python threads there is nothing to gain because it would block all 
other threads!

Only possible solution: have an RPC server on the backend capable of serving 
large blobs in small chunks on request.
Then the requesting widget would register a procedure in the "on idle" loop to 
while not finished:
        blob.add(backend_rpc.get_next_chunk(cookie, size))
display(blob)

OR



However, for compressed patient images of reasonable size I found no 
perceivable delay within a local network.
It is worth noting that for some reason a PyPGSL.PgSQL BYTEA data type appears 
to occupy MORE bytes than using Python's binascii.hexlify() function, and the 
latter appears to work faster too. This completely baffled me - but it 
becomes obvious when looking at the source code: non-printables are escaped 
with 4 bytes, NULL characters even with 5 bytes, and several other special 
cases involving quotes and slashes using multiple bytes for encoding. The 
code scans byte per byte with branching after every byte evaluation.
Hexlifying simply converts every byte into it's 2 byte Hex representation - 
quoteproof, foolproof, predictable (always blowing up the size by factor 2), 
and almost an order of magnitude faster (simple lookup in small table, no 
branching etc.)

So what I do is hexlify the data and use it without further 
escaping/conversion as Postgres BYTEA data type directly.

Horst