Re: [Gnumed-devel] gmBackendListener vs. gmDispatcher

[Horst Herb]

Karsten Hilbert wrote:
> Shouldn't both of those services be available through one and
> the same API with one optional parameter
> (source = client|backend) ?

I thought of this one. But I reckoned that it is less confusing when we 
clearly separate aynchronous backend notifications from client internal 
signalling.

> The only advantage I can see in keeping them separated would
> be not having to import both modules if some application
> doesn't want to use one or the other (as in import-med_docs.py

The back end listener costs valuable processing cycles, as the example 
demonstrates (try 'python gmBackendListener.py'). Thus, it should not be 
needlessly invoked. It also opens it's own conections to the backend, 
using more valuable ressources. Thus, it shoud be specifically started 
only when need arises.

> 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.

Horst