rename table client -> engine interface

[nicklan]

Simple rename of TableClient to EngineInterface and table_client to engine_interface.

I was going to do this as part of the big PR for data passing, but I think actually doing this first will make the review less painful, so I've pulled it out.

Doesn't touch DefaultTableClient yet, that can be renamed separately.

[roeap]

👍

[ryan-johnson-databricks]

This is definitely an improvement, but part of me wonders whether "client" is just plain the wrong word? This is more like an EngineInterface concept, no?

[zachschuermann]

just to throw another idea out: what about just Engine trait?

[roeap]

people may be tired of hearing this, but there happens to be a somewhat famous saying around naming things in CS 😆.

Just thinking out loud here, but to me, Client immediately invokes thinking about client-server interactions, which may not be what we are doing here.

I guess what we are asking from the engine is to provide us with a set of capabilities - implement a specific API - which may a case for EngineInterface.

Since we are essentially saying, that the engine side of things should do all the heavy lifting - i.e. without it out actions are just empty statements, it may be called just Engine as well.

Somehow the thing that is somehow special to me here, that we are also asking the engine to provide us with a data format it wants to work with, so its not only implementing the execution of actions but also what these actions should act on ...

not sure if this is correct, but Kernel invokes the notion of an OS, no? I may be wrong here, but if an OS interacts with another system would that be what is called a Driver?

Looking at may ramblings this may not even be helpful 😆. I guess EngineInterface would maybe be the most generic term, which would let us call the existing system the engine, which implements the engine interface ...

[roeap]

one more thought came up - in query engine terms, is kernel maybe doing the planning, and the engine is doing the execution?

[roeap]

going out on a limb here, and thinking also about the ffi case. since the top level thing is not doing anything and just providing us access to the specific sub capabilities - is it maybe just an EngineHandle?

[ryan-johnson-databricks]

going out on a limb here, and thinking also about the ffi case. since the top level thing is not doing anything and just providing us access to the specific sub capabilities - is it maybe just an EngineHandle?

It's quite likely FFI code will surface a notion of "handle" soon, to identify data structures defined by kernel or engine that are opaque to the other. Hopefully without giving up the last remnants of strong typing. That's still under heavy prototyping tho, so we probably shouldn't wait for it to stabilize before merging this PR.

[zachschuermann]

lgtm

[ryan-johnson-databricks]

Nice!