Make subscriptions more go-centric about goes HOT 5 OPEN

Definitely!

from goes.

I'm thinking we should have a consume method on the subscription that returns two channels and an error, the first channel would provide access to the events rendered to that subscription and the second would provide access to the reason a subscription was terminated.

This would then allow the use of the select block to iterate over messages appearing on both channels simultaneously.
How does this sound? Also, what tests should we have for this?

from goes.

@SeanFarrow i'm keen to see how this would work out. Is this a bad approach? https://github.com/pgermishuys/goes/blob/master/eventstore/subscription.go#L47

from goes.

@pgermishuys,
I'm not saying it's a bad idea, just that it's not as go centric as other messaging solutions.

If you look at the way amqp does this,
here
You create a channel, which would be equivalent to a subscription, then consume from that, giving you a go channel, which closes once no more items are available.

Given the client provides the reason why the subscription was terminated, I'm suggesting we do one of the following:
Either add an item envelope structure that can either hold an event or an object detailing why the subscription terminated.
Or (the prefered option), Have two channels returned from a consume method on the subscription that could both be iterated over.
Having a consume method would replace start in my thinking. so you would create the subscription, then consume from it.

Hope that makes sense.

from goes.

It makes sense! thanks for the explanation!
Let's do it!

from goes.