Mailing-List: contact dev-help@flink.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flink.apache.org
MIME-Version: 1.0
Sender: drfloob@gmail.com
From: AJ Heller <aj@drfloob.com>
Date: Fri, 9 Sep 2016 11:46:02 -0700
Message-ID: <CABF4bxY2D3RPSUc-H1eZk-qTOdbQ5ybh0_ofGLoH399zU2ZWQw@mail.gmail.com>
Subject: Implementing FLIP-2 and FLIP-4
To: dev@flink.apache.org
Cc: Aljoscha Krettek <aljoscha@apache.org>, Vishnu Viswanath <vishnu.viswanath25@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c0b7ad814651a053c17907e
archived-at: Fri, 09 Sep 2016 18:46:27 -0000

--94eb2c0b7ad814651a053c17907e
Content-Type: text/plain; charset=UTF-8

Thank you for offering your support, I'm excited to dig in!

I have some work to do getting up to speed on the windowing internals. And
I still need to get my bearing on the Evictor changes, I plan to read
through the list archive and documents today. Vishnu, are your changes
already publicly viewable?

Regarding the window modifications in FLIP-2, I see Vishnu that you've
suggested an interface for the EvictorContext object, and Aljoscha, you
suggested an abstract Context class. Does it make sense for them to agree?
The other big difference I've seen in the signatures is wheter the Window
is contained in the context or not.

Have you considered modifying the signature of the methods to accept `<C
extends Context>` or `<EC extends EvictorContext>`? At least in terms of
FLIP-2, this would allow each process window function to define and work
with its own context (without downcasting, anyway), and similarly in the
future, there'd be less work in changing Context subclasses when new
abstract methods are added to Context.

But I may be getting ahead of myself. Could you point me towards where
contexts are/would be created? I'm not clear on the ownership and lifecycle
of these objects yet.

--94eb2c0b7ad814651a053c17907e--