> I would be happy to go through and try to put together something for that ... > At the very least it should get its own DISCUSS thread and then be written > up in the wiki.
+1. Thanks. > On Nov 9, 2021, at 11:43 AM, Jeremiah D Jordan <jeremiah.jor...@gmail.com> > wrote: > > I would love to have this discussion and setup annotations or similar to > formalize things. I just do not think we need to hold any up CEPs to do so. > That discussion should possibly be a CEP of its own proposing how we want to > formalize interfaces? I would be happy to go through and try to put together > something for that or since you feel so strongly about it maybe you want to > David? At the very least it should get its own DISCUSS thread and then be > written up in the wiki. > > -Jeremiah > >> On Nov 9, 2021, at 1:06 PM, Joshua McKenzie <jmcken...@apache.org> wrote: >> >>> >>> trunk -> anything goes, not trunk -> try not to change these interfaces >> >> Have we ever clarified what "these interfaces" are? Was just talking to >> David and I realized I didn't even JavaDoc CommitLogReadHandler as _being >> designed_ for external usage. /sigh >> >> I think it'd be valuable for us to go through the codebase and annotate >> interfaces as intended to be exposed to 3rd parties; this has bothered me >> for years. Especially as we come up on a large number of new cleanups, >> refactorings, and potentially genericizing some subsystems into API's >> (CEP-18 descendents). >> >> >> On Tue, Nov 9, 2021 at 2:01 PM David Capwell <dcapw...@apple.com.invalid> >> wrote: >> >>>> We already have many interfaces similar to these for Compaction >>> Strategy, Indexing, Query Handler. >>> >>> Today-I-Learned QueryHandler is not allowed to be touched in a minor… good >>> to know… >>> >>>> not trunk -> try not to change these interfaces >>> >>> Outside of MBeans, I honestly do not know what interfaces fall into this >>> group; and for MBeans we have tests which block breaking changes. The >>> point I am making is that not everyone is aware of the rules, so having >>> something in place to help enforce such rules should be thought about; if >>> we want to add pluggable hooks with the intent that external parties can >>> leverage such hooks, we should also add to the scope the maintenance of >>> these interfaces (we should not assume “tribal knowledge” will work). >>> >>> I am not trying to ask for something large or something requiring a ton of >>> work, I am just asking that this gets thought about during the project so >>> it doesn’t get neglected. This could be as simple as an annotation like >>> @ExposedTo3rdParties (Hadoop does this to show an interface is exposed and >>> must be maintained), or it could be something like split directories >>> (src/java = private, src/java-exposed = public); I am trying not to dictate >>> an implementation, only trying to make sure we are setup to support the CEP >>> after the work is done. >>> >>> >>>> On Nov 9, 2021, at 9:52 AM, Jeremiah D Jordan <jeremiah.jor...@gmail.com> >>> wrote: >>>> >>>> We already have many interfaces similar to these for Compaction >>> Strategy, Indexing, Query Handler. I would hope that commiters are already >>> following a policy along the lines of trunk -> anything goes, not trunk -> >>> try not to change these interfaces. I would expect that to be the same >>> policy for any new internal interfaces that are added. But given we >>> already have many such interfaces, I see no reason to block adding more of >>> them while change policies are discussed. >>>> >>>> -Jeremiah >>>> >>>>> On Nov 9, 2021, at 10:44 AM, David Capwell <dcapw...@apple.com.INVALID> >>> wrote: >>>>> >>>>> I still have one outstanding comment, but this is a comment for several >>> of the CEPs being worked on >>>>> >>>>>> And last comment, which I have also done in the other modularity >>> thread… backwards compatibility and maintenance. It is not clear right now >>> what java interfaces may not break and how we can maintain and extend such >>> interfaces in the future. If the goal is to allow 3rd parties to plugin >>> and offer new SSTable formats, are we as a project ok with having a minor >>> release do a binary or source non-compatible change? If not how do we >>> detect this? Until this problem is solved, I do not think we should add >>> any such interfaces. >>>>> >>>>> I would love some clarity on this. Specifically, if we assume a patch >>> author/reviewers are not familiar with the impact of changes these >>> interfaces, what happens? Do we have tools to block this? Do we require >>> 3rd party authors to create massive shims to deal with every patch level >>> version out there? I would love more clarity on how we maintain these new >>> pluggable interfaces. >>>>> >>>>>> On Nov 9, 2021, at 4:45 AM, Branimir Lambov <blam...@apache.org> >>> wrote: >>>>>> >>>>>> Does anyone have any further comments or questions on the proposal, or >>> are >>>>>> we ready to move forward to a vote? >>>>>> >>>>>> Regards, >>>>>> Branimir >>>>>> >>>>>> On Tue, Nov 2, 2021 at 7:15 PM David Capwell >>> <dcapw...@apple.com.invalid> >>>>>> wrote: >>>>>> >>>>>>>> I apologize I did not mention those things explicitly. All the places >>>>>>> where >>>>>>>> sstable files are accessed directly would have to be refactored. >>>>>>> >>>>>>> Works for me >>>>>>> >>>>>>>> Speaking about the implementation, one idea I was thinking about was >>> that >>>>>>>> the factories for formats are registered using Java's native service >>>>>>>> loader. >>>>>>> >>>>>>> I am a fan of ServiceLoader as a means of plugging in. >>>>>>> >>>>>>>> I hope this explains a bit >>>>>>> >>>>>>> Yep; thanks! >>>>>>> >>>>>>>> On Nov 2, 2021, at 1:46 AM, Jacek Lewandowski < >>>>>>> lewandowski.ja...@gmail.com> wrote: >>>>>>>> >>>>>>>> David, >>>>>>>> >>>>>>>> I apologize I did not mention those things explicitly. All the places >>>>>>> where >>>>>>>> sstable files are accessed directly would have to be refactored. >>>>>>>> >>>>>>>> Regarding TableMetrics - currently it includes many metrics, some of >>> them >>>>>>>> are unrelated to sstables at all, but there are metrics which are >>>>>>> specific >>>>>>>> to the current sstable format, like metrics related to index >>> summaries or >>>>>>>> bloom filters. The created gauges query certain methods on sstable >>>>>>> reader - >>>>>>>> I think the only common metrics for sstables we can leave in >>> TableMetrics >>>>>>>> are those for which there are query methods in generic sstable >>> interface. >>>>>>>> Other metrics, specific to the certain sstable format should be >>>>>>> registered >>>>>>>> by the implementation itself. >>>>>>>> >>>>>>>> Speaking about the implementation, one idea I was thinking about was >>> that >>>>>>>> the factories for formats are registered using Java's native service >>>>>>>> loader. This way we could get the list of all the factories on the >>>>>>>> classpath and call some method, like `registerMetrics` during system >>>>>>>> initialization. That could be also implemented in static initializer >>> in >>>>>>> the >>>>>>>> factory but it would make it less obvious for the implementors where >>> such >>>>>>>> initialization should be done. >>>>>>>> >>>>>>>> I hope this explains a bit >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jacek >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>>> >>>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
