Alan Conway wrote:
We need to re-open the discussion on this. Currently a session is either
entirely sync or entirely async so your choices are safe but slow or
fast but risky.
Note you can change the mode between commands. So you can have it in
synchronous mode when performing any setup, then switch to async mode
when you wish to send lots of messages.
I've had user feedback that an intermediate mode which is sync for most
operations (declare, bind, subscribe etc.) but async for message
transfer. With this as the default, most applications would Just Work
without surprises and with good performance.
My feeling is we need to address this, but I know the above idea is
controversial - what do people think?
I've never been keen on this idea, but I can see the attraction and
wouldn't be opposed.
Another option would be to ditch the sync/async modes for session and
make it an explicit part of function names, so you'd have synchronous
declare(...) and asynchronous asyncDeclare(...). All our docs & examples
would use declare(), bind(), subscribe() etc. and asyncTransfer(...) so
things will Just Work for users that follow the examples.
I really don't like having separate methods. Having an (optional?)
argument per method that indicated whether it was sync or not would in
my view be nicer.
Having written that, I think I like it: It becomes 100% explicit from
the code what is intended, which is good for something with such
potentially dangerous and confusing consequences. The only "feature" of
a modal session that you lose is the ability to make the same code run
sync or async, but that seems to me more like a bug than a feature to me
:) We can of course offer both options (modal and explicit versions) if
there's really need.
