Thank you for the analysis Jungtaek. I particularly appreciate your admitted 
bias as a big contributor to storm-SQL.

It will take time for us to sort out how the merge will happen. Similar to what 
we are discussing with Kafka and ES, we could support two versions of SQL, and 
eventually deprecate the one one that has the least traction.

I'd rather not do that if possible. I'd rather see the community rally around a 
(TBD) approach to a single SQL interface. SQE has an advantage that it used in 
production, but being newly donated/open sourced, it does not have much of a 
user community. Storm-SQL has the same community issue, likely because it's 
never been announced. And it's never been announced because it hasn't been 
ready (missing MVP features).

It would be good to see some sort of analysis from the SQE devs who are more 
intimately acquainted with the SQE codebase.

-Taylor


> On Sep 21, 2016, at 7:02 PM, Jungtaek Lim <kabh...@gmail.com> wrote:
> 
> Hi dev,
> 
> While code contribution of SQE is in progress, I would like to continue
> discussion how to merge SQE and Storm SQL.
> 
> I did an analysis of merging SQE and Storm SQL in both side, integrating
> SQE to Storm SQL and vice versa.
> https://cwiki.apache.org/confluence/display/STORM/Technical+analysis+of+merging+SQE+and+Storm+SQL
> 
> As I commented to that page, since I'm working on Storm SQL for some weeks
> I can be (heavily) biased. So I'd really appreciated if someone can do
> another analysis.
> 
> Please feel free to share your thought about this analysis, or another
> proposal if you have any, or other things about the merging.
> 
> Thanks,
> Jungtaek Lim (HeartSaVioR)

Reply via email to