[Dx4win] OmniRig

[Radivoj Kar, F6GNZ]

Hi Jim,
I understand. But I thought that there was no problem with it: when data changes, info will be kept in OmniRig and reported next time when DX4WIN polls OmniRig. Is there a problem with it?
73, Radi





Le Dimanche 16 mars 2014 17h08, Jim Reisert AD1C <jjreisert at alum.mit.edu> a écrit :
 
On Sun, Mar 16, 2014 at 4:19 AM, Radivoj Kar, F6GNZ wrote:
>
>
>> But. looking in the OmniRig's configuration window, there are well a polling time and time-outs specified, like in DX4WIN. Running the OmniRig's  Client.exe program one can see that Omnirig polls the radio and changing the frequencies/modes on the rig are well reflected in the Client.exe window.  But I may have not well interpreted what Paul exactly meant with "OmniRig is event driven" ....
>
>Hi Radi,
>
>I am going to take a stab at this...
>
>There are generally two ways to get data.  One is the PULL model,
>where you continually ask the source if new data is available.  When
>the data finally changes from the last time you asked, you do
>something with it.  This is the same as POLLING.  It's like being
>blind, and having to ask the person next to you if the score in the
>football match has changed yet.  When it does change, you stand up and
>cheer.  Depending on how often you ask, it could be minutes after the
>goal before you stand up and cheer.
>
>The other is the PUSH model.  The source of the data only sends it to
>you when it changes.  It doesn't have ears, only a mouth, so it can't
>respond to queries.  Like the scoreboard at a football match.  DX4WIN
>would just sit and wait for Omnirig to tell it the that the radio
>changed.  This is known as event driven.
>
>DX4WIN only knows how to ask for data, i.e. polling.  It doesn't know
>what to do with data that is given to it without asking.
>
>-- 
>Jim Reisert AD1C, <jjreisert at alum.mit.edu>, http://www.ad1c.us
>
>