Make subscriptions more go-centric

[SeanFarrow]

Having looked at this, it would be nice if subscriptions used go's channel construct.

Doing this would allow the use of a goroutine to process events/errors from subscriptions.

[pgermishuys]

Definitely!

[SeanFarrow]

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?

[pgermishuys]

@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

[SeanFarrow]

@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.

[pgermishuys]

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