René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Declare imglib2 functions as ops","articleBody":"Ensure imglib2-algorithm can declare all its functionality as ops in a dependency-light (or even dependency-free—e.g. XML? Spring? see #55) way.\r\n\r\nOf course, the imglib2-algorithm-side work is not technically part of scijava-ops, but we want to be 100% confident the architecture will support this.\r\n\r\nWe need to decide how to consume imglib2-algorithm from Ops. Possible approaches:\r\n\r\n1. [CURRENT] Leave imglib2-algorithm alone. Wrap all algorithms in imagej-ops.\r\n    * Pro: No changes needed to imglib2-algorithm. No new dependencies.\r\n    * Con: Tons of boilerplate. Does not evolve with additions to imglib2-algorithm. Extra maintainer effort from people less close to the imglib2 project.\r\n2. ServiceLoader. Change imglib2-algorithm to:\r\n    * Annotate static methods as @OpMethod / @OpField of an OpCollection.\r\n    * Make classes implement the correct functional interface.\r\n    * Declare all implementations according to ServiceLoader mechanism (e.g. for Java 9+, in module-info.java).\r\n    * Pro: Automatically expose algorithms as ops for the matcher, without depending on the matcher!\r\n    * Con: Dependency on ops functional interfaces (function, computer, inplace). Need to manually edit module-info.java to declare your op implementations (potential action-at-a-distance errors waiting to happen)—unless we impose an additional compile-time indexing mechanism of some kind.\r\n3. ServiceLoader with compile-time indexing.\r\n    * As (2) above, but with scijava-indexer, or Spring indexer, or something, so you don’t have to maintain your module-info manually.\r\n    * Pro: Reduce action-at-a-distance errors/skew.\r\n    * Con: Another compile-dependency (but maybe can be hidden in pom-scijava! Depends where the annotation interface(s) being used live—research needed).\r\n    * This approach can be “added on” to B perhaps, and can wait to explore till later.\r\n3. Go all-in on Spring, with all algorithms discoverable via Spring-based discovery (which mechanism? TBD).\r\n    * Con: Adds big dependencies to imglib2-algorithm. (Or _does it_?)\r\n    * Pro: Unified framework across more of our ecosystem, as SciJava 3 adopts Spring in general for its context-aware layers.\r\n\r\n-------------------\r\n\r\nAdditional notes:\r\n\r\n* Make scijava-function component with ONLY the functional interfaces.\r\n    * org.scijava.ops.function -\u003e org.scijava.function\r\n    * NO dependency on ServiceLoader. Just paves the way.\r\n    * OpCollection and `@OpMethod` and `@OpField` and `@OpDependency`?\r\n        * `@OpMethod` declares functional type—but this could potentially be inferred if we instead have people annotate `@Container` and `@Mutable` on their method parameters.\r\n            * Another potential advantage of this could be that your component does not need to depend on org.scijava.function at all, then—only on the `@Container` + `@Mutable` annotation classes… but see next point about op name declaration...\r\n            * Those annotations could live in scijava-ops-api in that case?\r\n    * `@OpMethod` and `@OpField` declare fully qualified op name including namespace—maybe no elegant way to get around this.\r\n* As an experiment, see if imglib2-algorithm can depend on scijava-function, and the algorithms there can implement the right functional interface, and module-info can declare those algorithms as implementations.\r\n* Then see if you can depend on imglib2-algorithm in a downstream project (e.g. imagej-ops2) and discover all the imglib2-algorithm implementations as Ops!\r\n* Once we have working options, present them to the ImgLib2 maintainers to discuss tradeoffs.","author":{"url":"https://github.com/ctrueden","@type":"Person","name":"ctrueden"},"datePublished":"2021-04-29T14:34:13.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":10},"url":"https://github.com/56/scijava/issues/56"}