streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Franklin <m.ben.frank...@gmail.com>
Subject Re: Proposing Changes to the StreamsProvider interface and StreamsProviderTask
Date Tue, 13 May 2014 19:38:05 GMT
On Tue, May 6, 2014 at 10:53 PM, Matthew Hager [W2O Digital] <
mhager@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.

>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message