[Top][All Lists]

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

Re: [Gnumed-devel] gmBackendListener vs. gmDispatcher

From: Horst Herb
Subject: Re: [Gnumed-devel] gmBackendListener vs. gmDispatcher
Date: Mon, 09 Sep 2002 11:22:55 +1000
User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1a) Gecko/20020611

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

The back end listener costs valuable processing cycles, as the example demonstrates (try 'python'). 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
"" 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.


reply via email to

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