To: stik@ON-Luebeck.DE
Subject: Re: [3] STIK: Some news                                                         


On Tue, 22 Oct 1996 12:22:51 Peter Rottengatter <perot wrote: 
>
>
>On Tue, 22 Oct 1996, Ronald Andersson wrote:
>>
>> This means that we must resist the temptation of using different codes for various
>> types of STiK events, or to handle different channels etc, since that would make
>> the risk of conflict with extended keyboard codes greater.  All such info must
>> be kept in STiK-defined structures and tested by each client/module to determine
>> what kind of STiK-event this pseudo-key represents.
>
>It's not needed anyway. The key event is only for waking the application, 
>it then can look into STiK's data arrays, of whatever method else comes 
>into mind, to check for type of event, channel, etc.

The need for such structures will probably grow though, when/if we start using
multiple clients.  By the time a client 'wakes up' STiK may already have started
preparing a new package for another client, which could cause a conflict if only
global flags are used.


>> The inability to ensure that keyboard data reaches the intended client also means
>> that it will be necessary to continue 'stuffing' the event code into the buffer,
>> until the intended recipient responds, and this is where we can hit a brick wall.
>
>Agreed, there should be a carefully selected timeout until STiK sends the 
>code again.

Yes.  Doing it too often would be a waste of time, but each 'miss' will delay
the ultimate client response and effectively lower the throughput.


>> If an ACC (or other APP) is currently 'topped', it doesn't matter how much we
>> stuff the code into the buffer, because the intended client will _never_ get it.
>
>This is a problem. Any other suggestions, that are legal, and should work 
>better ?

Well, one way to diminish the problem is to revive the event-scheduler idea,
but for keyboard events this time.  All STiK APPs would then be forbidden to
ask evnt_multi for keyboard events, and required to request them through the
scheduler instead.

This would mean that keyboard events could awaken any STiK client, even though
AES only directs them to a single APP/ACC.  Unfortunately this does not solve
the problem of conflicts with unrelated APPs/ACCs, which could prevent these
events from waking the scheduler itself.

Any scheme I can think of to do that, still requires timer events and is also
likely to have a disturbing effect on some APPs/ACCs (forced untopping etc.),
so we'd probably be better off with a purely time-based event-scheduler.
I'm afraid I see no other fully legal method to do the job reliably.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
