Re: [Gnumed-devel] gmBackendListener vs. gmDispatcher

[Karsten Hilbert]

> >BTW we need a way for senders to give listeners a way to know
> >what has changed. If I change patient A while someone else
> >looks at patient B they are certainly not interested in being
> >notified about patient A being changed ...
> 
> Not so easy to implment on the backed side, since the notification 
> protocol does not allow parameters other than the backend PID. (AFAIK - 
> would be happy to learn otherwise). Thus, one needs an extra query or a 
> pseudo-table for quick lookups.

> >As the backend listener is specific to a backend anyways it
> >might make sense here to pass around OIDs or strings like
> >"identity.id=3193" as payload to backend notifies (such as
> >"patient_changed" for this payload example).
> 
> See notification protocl, which does not allow (?) parameters. At 
> present I can't see how we can avoid a re-query.
We won't be able to avoid a re-query. I am not asking for what
I explained Hilmar we wouldn't do :-)  But I want to avoid
unnecessary queries. Just think of the following:

Client A              Client B
--------------------------------------------------
opens Patient XY,
registers interest
in changes to pa-
tients,
                      opens Patient WV,
                      changes WV's Med's list,
                      posts patient_changed signal,
receives signal
"patient_changed",
reloads patient XY
although that is
completely bogus ???


We currently have 117000 unique patient records in our
database so there's a 1:117000 chance of missing the point
(actually there's a chance of roughly 1:25 since those 25
patients in the waiting room are way more likely to get
accessed by two clients simultaneously).

However, we would need to restrict ourselves to a patient ID
since if we don't we don't know at what level of detail we
want to stop passing things around.

Reading up on the docs shows the following bits:

a) The PID being returned in a NOTIFY message allows to
distinguish between notifies from us and from other clients
(since each client has its own backend PID).

b) Indeed there's not payload to NOTIFY. However, the name of
   the signal is arbitrary. We may thus use convention to pass
   around the appropriate patient ID: patient_change_XXXXX
   where XXXXX is the ID in question. Listeners must listen
   to patient_changed_(ID of current patient) then.

Is this practical ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346