Hi All, I'm sending this email hoping to confirm alignment of the Polaris community members on SPI development principles in this project. I do not think we need strong and formal rules / guidelines as long as the community has consensus on the general approach.
Recap: SPI = Service Provider Interface * What is the difference between API and SPI? API is meant to be invoked by a client on a library (or service) in order to cause the library (service) to perform a certain action. SPI is meant to be implemented by a library / service plugin in order to provide a method for performing certain actions when multiple alternatives exist. Example from Polaris: IcebergRestCatalogApiService is an API that represents the IRC spec in terms of java classes. Authenticator is an SPI that defines what Polaris code requires an authorization framework to implement. The default impl. is DefaultAuthenticator, OPA and Ranger implementation and alternatives that can be plugged in via CDI + configuration. * Where should SPI classes be located normally? Without considering the legacy code in Polaris, I believe SPI classes should be located such that they require minimal depdency leaks into the module implementing the SPI. Ideally all SPI classes used by module X should be located in a module "X-spi" to convey that they are associated with X. This is not to say that existing code must be refactored immediately to fit these patterns. This is a proposal for future evolution. If module X can be expected to be a dependency of its SPI implementations, the SPI classes can be placed inside X itself. * Should SPI classe be in polaris-core? If polaris-core requires defines a plugin point, the SPI for that can certainly be in polaris-core. BasePersistence is an example of a core SPI. * Can SPI interfaces have breaking changes from the java language perspective? Yes. Unline API, SPI interfaces define what plugins must implement. not what clients rely on. For example, adding a parameter to an SPI method will cause a compilation error downstream, but it's ok. This is a signal to the downstream SPI implementation that it is expected to process the new parameter. It is a good breakage in the sense that it will inform the downstram implementation and prevent invalid behaviour that might occur as a result of ignoring the new parameter. In many cases this is not a hard failure downstream. Normally, the downstream project will get those compilation errors inside a PR that updates its Polaris dependencies. It will not be a deployment time error (which is common with service API changes). Thoughts? Thanks, Dmitri.
