Subscribe API Enhancement proposal

[scottf]

Purpose

This is to propose additions to the subscribe api to accommodate common use of making a subscription against an existing (durable) consumer.

API

All api would operate as strict bind.

• The consumer must exist
• The consumer must be the proper type (push/pull) to match the request
• The consumer must not be push bound if the request is for push and consumer is not part of a deliver group

Push Sync

Get a synchronous push subscription (if sync is supported for the language):

bindSubscribePushSync(stream, consumerName)

Push Async

Get an asynchronous push subscription (if is supported for the language):

bindSubscribePushAsync(stream, consumerName, async_stuff_ie_callbacks_autoAck)

Pull

Get an asynchronous pull subscription:

bindSubscribePull(stream, consumerName)

[matthiashanel]

I like the idea. Since we discussed changes for push consumer, perhaps we should wait till those shook out.
Once that happened, I'm not 100% sure if all of the above restrictions are actually needed.

Say we can send a message to the push subscriber in order to receive data. (delivery subject is taken as the reply subject) Say we also hide that subject behind the same name as the pull subscriber's next subject. Now our initial request can provide a lot of valuable feedback, including wether the consumer exists or not or if it's the correct subscriber type for the access method the client choose. In theory we could then even create the durable if we wanted to.

[aricart]

JS simplification apis will handle this correctly.

[scottf]

Closing this issue as it is covered in simplification