Many ways to construct a Subscription without specifying message receipt options

[jganetsk]

The Subscription constructor takes an important options argument for configuring the receipt of messages: aka batching/flow control

https://cloud.google.com/nodejs/docs/reference/pubsub/0.19.x/Subscription#Subscription

But there are many ways to get a Subscription object without having the ability to specify these options:
https://cloud.google.com/nodejs/docs/reference/pubsub/0.19.x/v1.SubscriberClient#createSubscription (note these are a different set options that are required for the CreateSubscription call, but not for configuring the reciept of messages)
https://cloud.google.com/nodejs/docs/reference/pubsub/0.19.x/v1.SubscriberClient#getSubscription
https://cloud.google.com/nodejs/docs/reference/pubsub/0.19.x/v1.SubscriberClient#listSubscriptions

The Python library does this better... it decouples the Subscription as a noun from the verb of subscribing. Instead of taking these options in via constructor argument, a subscribe method is provided that takes these options: https://googlecloudplatform.github.io/google-cloud-python/latest/pubsub/subscriber/api/client.html#google.cloud.pubsub_v1.subscriber.client.Client.subscribe

However, this can't work given the way things are currently structured in the Javascript library, because the Subscription object is an EventEmitter. Therefore, a Subscription cannot exist without being already configured to receive messages. Alternately, you could make the Subscription object not be an EventEmitter, and (similar to Python) add a subscribe method that takes configuration and returns an EventEmitter.

[callmehiphop]

This seems reasonable to me. @stephenplusplus @jmdobry do you have any feelings here?

[stephenplusplus]

I would rather keep things the way they are, in that a Subscription is ready to emit messages whenever the user is. Another way we thought to solve this was adding a setOptions() (better name welcome): #12

[jganetsk]

I'm ok with either

…

On Sat, Sep 29, 2018 at 9:38 AM Stephen ***@***.***> wrote: I would rather keep things the way they are, in that a Subscription is ready to emit messages whenever the user is. Another way we thought to solve this was adding a setOptions() (better name welcome): #12 <#12> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#247 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABhCKsvLh44iDOrCa1Ipjq0V6eXP3ZEks5uf3fagaJpZM4WfiQt> .

[callmehiphop]

I'm going to close this since it appears to be a duplicate of #12