Am Montag, 30. September 2019 11:46:43 UTC+2 schrieb Barry Scott:
> > On 29 Sep 2019, at 21:41, Eko palypse wrote:
> >
> > Am Sonntag, 29. September 2019 19:18:32 UTC+2 schrieb Barry Scott:
> >>> On 29 Sep 2019, at 14:14, Eko palypse wrote:
> >>>
> >>> Unfortunately, I can't make all callbacks
> On 29 Sep 2019, at 21:41, Eko palypse wrote:
>
> Am Sonntag, 29. September 2019 19:18:32 UTC+2 schrieb Barry Scott:
>>> On 29 Sep 2019, at 14:14, Eko palypse wrote:
>>>
>>> Unfortunately, I can't make all callbacks synchronous or asynchronous
>>> because this has negative effects on the a
Am Sonntag, 29. September 2019 19:18:32 UTC+2 schrieb Barry Scott:
> > On 29 Sep 2019, at 14:14, Eko palypse wrote:
> >
> > Unfortunately, I can't make all callbacks synchronous or asynchronous
> > because this has negative effects on the application in one way or another.
>
> Surely you can ma
> On 29 Sep 2019, at 14:14, Eko palypse wrote:
>
> Unfortunately, I can't make all callbacks synchronous or asynchronous because
> this has negative effects on the application in one way or another.
Surely you can make all callbacks async?
You do not have to have them wait, they can complete
Am Sonntag, 29. September 2019 01:02:48 UTC+2 schrieb Paul Rubin:
> Eko palypse writes:
> > Two dicts, one for sync and the other for async registrations?
>
> Why not make all the callbacks asynchronous? Clients that don't want to
> handle a callback immediately can keep it pending until they ar
s
as the keys and lists of methods being the values.
Notification sent, triggers the list of method to be called. Nothing fancy.
Now, where it gets trickier is that the client should be able to register
synchronous and asynchronous callbacks because some of the actions can't be
done in a s
