+1 (non-binding) I successfully tested the coordinator with my TypeScript SDK. I also ran a DAG that mixed Java, TypeScript, and Python tasks in a single pipeline, exchanging data via XCom across all three runtimes. Every task ran successfully end-to-end.
@TP and @Jason Do you think we can include the typescript sdk as part of this AIP or will it require a separate AIP? In my opinion, it doesn't require a new AIP as it will be an extension of the coordinator. Regards, Shivam Rastogi On Sat, 16 May 2026 at 11:36, Stefan Wang <[email protected]> wrote: > +1 (non-binding). > > Thanks TP and Jason > > — really appreciate the way the discussion feedback got worked into the > design, and the coordinator-interface shape that came out the other side. > > Excited to see this land as the foundation for native multi-language task > support in Airflow. > > Best, > Stefan > > > > On May 16, 2026, at 3:30 AM, Zhe-You(Jason) Liu <[email protected]> > wrote: > > > > Hi TP, Jens, Jarek, and all, > > > > +1 (binding) from me as well. > > > > I really appreciate all the thoughtful feedback and comments from > everyone > > that helped make AIP-108 and the coordinator interface more concrete. I > > look forward to the coordinator interface becoming a strong foundation > for > > native multi-language task support in Airflow and for future language > > integrations as well. > > > > Thanks everyone! > > > > Best, > > Jason > > > > On Sat, May 16, 2026 at 6:27 PM Phani Kumar via dev < > [email protected]> > > wrote: > > > >> +1 (binding). Thanks TP, Jarek, Jens and Jason for the discussion and > >> alignment. > >> > >> On Sat, May 16, 2026 at 3:26 PM Jarek Potiuk <[email protected]> wrote: > >> > >>> +1 (binding) -> Thanks for being receptive to all comments TP / Jason. > >>> > >>> And regarding Jens' point: yes, "naming is difficult". However, at this > >>> stage, this name is just a "codename" because it's "Java only," > >>> "experimental," mostly used internally (except for the package name in > >>> configuration), and lacks a separate installable distribution (it's > just > >> a > >>> Python package name). When/If we turn it (hopefully soon) into > >> full-fledged > >>> coordinators - with common APIs and a compatibility strategy—it > **might** > >>> get real "coordinator" features; this might get handy. It might also be > >>> easier to "promote it" without migrations, which TP was rightfully > >>> concerned about. > >>> > >>> So, I actually like that it's named "coordinators" now in the Python > >>> package name because it allows for easy future evolution without > >>> unnecessary migration issues. I was far more sceptical about > implementing > >>> the new distribution naming schema at this point - because that would > >>> "anchor" us much more. I think our discussion resulted in a good middle > >>> ground: we avoid overcomplicating things (especially the development > >>> process, operational complexity, and intra-compatibility issues), > >> allowing > >>> us to get something "working" quickly, while ensuring we aren't blocked > >> and > >>> have a smooth path to implement the longer-term vision later. > >>> > >>> I think that was a very good discussion and outcome. Thanks again, TP. > >>> Also, thanks to (a bit more silent in this discussion) Jason for being > so > >>> flexible. I really appreciate it. I know firsthand how difficult it is > >> when > >>> a bigger vision you have is kind of trimmed-down, and when you see > where > >>> you want to go and others seem to "not see it". It forces you to twist > >> and > >>> turn things to not lose the track of the bigger vision, while taking > the > >>> first baby step toward it. But my experience is that the end result > might > >>> eventually benefit from learnings along the way, so trimming the first > >>> steps is a good thing (even if it's very difficult mentally). I've been > >>> doing it for years in our dev environment. While it generally follows > my > >>> initial vision, it's very different now due to incremental steps and > >>> tooling improvements along the way. > >>> > >>> J. > >>> > >>> > >>> On Sat, May 16, 2026 at 10:52 AM Shahar Epstein <[email protected]> > >> wrote: > >>> > >>>> +1 (binding), well done TP and Jason. > >>>> > >>>> > >>>> Shahar > >>>> > >>>> On Sat, May 16, 2026 at 10:02 AM Tzu-ping Chung via dev < > >>>> [email protected]> wrote: > >>>> > >>>>> Hi all, > >>>>> > >>>>> I’m calling vote on AIP-108: Java Task SDK and the Language > >> Coordinator > >>>>> Layer > >>>>> AIP-108 Java Task SDK and the Language Coordinator Layer - Airflow - > >>>>> Apache Software Foundation < > >>> https://cwiki.apache.org/confluence/x/pY4mGQ> > >>>>> cwiki.apache.org <https://cwiki.apache.org/confluence/x/pY4mGQ> > >>>>> [image: favicon.ico] <https://cwiki.apache.org/confluence/x/pY4mGQ> > >>>>> <https://cwiki.apache.org/confluence/x/pY4mGQ> > >>>>> > >>>>> Discussion thread: > >>>>> lists.apache.org > >>>>> <https://lists.apache.org/thread/gjot4bxj9kygj2fk76kx6tyg8s4hr057> > >>>>> [image: favicon.ico] > >>>>> <https://lists.apache.org/thread/gjot4bxj9kygj2fk76kx6tyg8s4hr057> > >>>>> <https://lists.apache.org/thread/gjot4bxj9kygj2fk76kx6tyg8s4hr057> > >>>>> > >>>>> > >>>>> The vote will run for 5 days until Thursday, 21st May 2026, 07:00 > UTC. > >>>>> > >>>>> Everyone is encouraged to vote, but only PMC members and Committers' > >>>>> votes are considered binding. > >>>>> > >>>>> Please vote accordingly > >>>>> > >>>>> [ ] +1 Approve > >>>>> [ ] +0 no opinion > >>>>> [ ] -1 disapprove with the reason > >>>>> > >>>>> Consider this my +1 vote (binding) > >>>>> > >>>>> TP > >>>>> > >>>> > >>> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
