I will answer with what is IMHO:
> 1a. If the destination contains, say, 20 messages, does it deliver 20
> messages or does it wait for a further 30 to arrive before calling
> onMessages()?
>
The implementation would be able to make a callback to the server and
verify if the server's destination is empty, and flush it case it's
empty.
We could add support for an optional timeout argument. Say, you would
flush if the client buffer didn't get a message in X milliseconds (or
seconds).
> 1b. If the destination is initially empty, and messages are being addded to
> the destination at 10 messages every second, how many messages are delivered
> in each batch?
>
Same as 1a. If we add the support for a timeout it would be up to the
user what to do. Either flush the current buffer or wait it complete
with 50 messages.
> 2. Do you care whether these messages are consecutive? (if there were more
> than one consumer on the same queue then they might not be)
>
I think we should keep the same semantics currently all the providers
(I know) have,. i.e. Messages are in order but not required to be
consecutive. (if more than one consumer on the queue). We just need to
keep the same semantic as we had with a single call to onMessage.
> 3. I note you say that auto-ack would ack them all in a single batch. Were
> you expecting client-ack and local transactions to behave as now (so a call
> to acknowledge() or commit() would ack or commit all the messages delivered
> by the session, not just those in the batch), or were you thinking of
> something different?
Same thing.. We are just merging several onMessage calls into a single call.
That means this for client ACK:
onMessage(Message[] messages)
{
messages[20].acknowledge(); // it would ack up to the message[20]
+ anything already acked on the session.
}