On Tue, May 6, 2014 at 10:53 PM, Matthew Hager [W2O Digital] <
mha...@w2odigital.com> wrote:
<snip />
> StreamsResultSet - I actually found this to be quite useful paradigm. A
> queue prevents a buffer overflow, an iterator makes it fun and easy to
> read (I love iterators), and it is simple and succinct. I do, however,
> feel it is best expressed as an interface instead of a class.
I agree with an interface. IMO, anything that is not a utility style
helper should be interacted with via its interface.
> The thing missing from this, as an interface, would be the notion of
> "isRunning" which could easily
> satisfy both of the aforementioned modalities.
>
Reasonable.
> Event Driven - I concur with Matt 100% on this. As currently implemented,
> LocalStreamsBuilder is exceedingly inefficient from a memory perspective
> and time execution perspective. To me, it seems, that we could almost
> abstract out 2 common interfaces to make this happen.
>
> * Listener { receive(StreamsDatum); }
> * Producer { push(StreamsDatum); registerListener(Listener); }
>
> Where the following implementations would place:
>
> * Reader implements Producer
> * Processor implements Producer, Listener
> * Writer implements Listener
>
Seems logical. I would like to see the two possible operating modes
represented as distinct interfaces.
>
>
