Re: sync needed in fanout example?

[Alan Conway]

Jonathan Robie wrote:
Alan Conway wrote:
It's also used in the pub-sub examples. It is needed in any situation 
where you are creating and binding private queues. You must be sure 
the private queues are all in place before you tell the publisher to 
start publishing. For examples that are run by hand you'll probably 
never see a problem, but the automated verify tests will fail about 
half the time if you take this line out.

It would be worthwhile to expand on the comment in the exampels and/or 
discuss this in the tutorial, it's not obvious from the current 
comment what this is for.

Is this something that can be fixed in future versions? I'll keep it in 
the examples for now and document it, but that makes the API rather 
fragile.

Jonathan

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.

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?

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.

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.