gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Introducing myself and questions on billing/accountin


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Introducing myself and questions on billing/accounting
Date: Fri, 20 May 2011 12:02:07 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, May 20, 2011 at 01:15:19AM -0700, Jim Busser wrote:

> > One way this can happen, technically, are hooks
> > like
> > 
> >     "post-encounter-creation"
> > 
> > and/or
> > 
> >     "post-encounter-modification"
> > 
> > upon which local code in the hook script can execute locale
> > specific billing code (*that* code, in turn, may well live
> > inside GNUmed, it's only about how it gets executed). Said
> > code would pull locale-billing-specific details from
> > wherever it wants to store such things.
> 
> 
> In the wiki, I had previously cached
> 
>       As soon as any user or widget would decide it is time to
>       issue a claim or a billing, the widget may send a message
>       with parameters {code:value, comment:text ...} via dispatcher.
>       If you have a billing backend in place, it will get the message
>       and act accordingly. If you have no billing backend or don't
>       need the feature, the message will simply (automatically) be ignored.
> 
> Is "dispatcher" connected to or independent of the hooks framework, and is it 
> relevant to interaction between GNUmed and LSMB?

A signal is pushed.

The dispatcher is a facility to send/receive signals. The
receiver must actively register that it is listening and
must listen ready to receive. 

A hook is pulled.

The hook script just sits there on your hard drive. It is
being invoked by the hook framework. It is not listening in
any way rather it just exists until invoked.

Of course, many signals having originated in the database
(say, after adding a test result) will effect the hook
script to be invoked with the appropriate hook name.

Another way to put the difference:

Code reacting to signals (from the dispatcher) lives inside
GNUmed while code being executed when a particular hook is
pulled lives outside GNUmed.

Imagine a Starship Destroyer class floating in space.
There's docking stations (external APIs) for various small
spacecraft on its belly. From each dock a laser tractor
beam emanates (the hook). It will then depend on whether a
Klingon glider has attached itself to the tractor beam or
not. The Starship Destroyer doesn't care. It simply emanates
the laser whenever it feels appropriate.

One glider may have attached to the "refill fuel" beam while
another will have attached to "replenish oxygen".

But both will need to wait (lie dormant) until fuel or
oxygen are actually pushed out from the dock (the hook is
pulled).

Feel free to improve the Wiki if you think this could
benefit from more documentation.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

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