rusackas commented on issue #35003: URL: https://github.com/apache/superset/issues/35003#issuecomment-3849522844
> More importantly, the Superset semantic layer would be just one next to others (Minerva, DJ, Snowflake, Cube, Mallow, OSI). It would have clear interfaces, and it would be easier to extend... To me, this is one of the "juicy bits" of the proposal, and something we should be doing as part of the Extensions effort in general. It's easy to fall for the temptation of adding Extensions alongside (or overriding) the existing Superset functionality as an alternative. But migrating the existing Superset feature to be a built-in Extension serves a few key goals: 1) Defines the interface in a way that _for sure_ supports Superset's current needs and functionality 2) Make sure that our tests and day-to-day users are effectively hardening that interface 3) Shrinks the "core" codebase, making sure that the feature can be maintained/improved/release independently, reducing maintenance burden on the core codebase. Over time, I would expect _many_ of our core competencies will become built-in extensions, and a world of alternative options will proliferate around them. Then Superset becomes a Data Access Platform limited only by its API / MCP / Components more so than the built-in features that come with it in the box. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
