Support "1-to-n" Commands

[gab1one]

Commands in this category create several rows as output for a given input row.

• Column names must be unique SciJava-Nodes should create unique column names #19
• RowIds must be unique
• The following modes must be supported:
  • Append
  • Replace
  • New Table
• The node has the Nodetype "Manipulator"

[dietzc]

Nodes in this category take one input row and produce several output rows.

[gab1one]

This issue was moved to knime-ip/knip2#15

[dietzc]

why did you move this to knip2? this issue is not image processing specific!

[dietzc]

@hornm @gab1one we need to think carefully how to represent 1-to-N commands. We need to define:

• How is the spec determined?
• Where does the developer put rows?
• How to represent a row?

One obvious solution would be: We add a method, called pushRow to such plugins which allows the user to push the currently set type=ItemIO.OUTPUT values into a row. Like this we won't have to additionally define a spec as it is defined via the parameters types of the plugin.

Another solution would be that we offer a method called addRow(Object...). However, then we would need a spec method.

Any other ideas?

[gab1one]

We could create a ResultRowService of some kind which collects rows pushed to it. I think pushRow() is the better approach, it ensures that all rows have the same spec and you can't accidentally create invalid rows.

[dietzc]

however, pushRow() is implying that our nodes are somehow state-machines. I'm not sure if this a problem. But I don't see a nicer way than doing it like that.

[hornm]

Don't we have to wrap potential 1-to-N-commands with KNIME-specific commands anyway? If so, then we could do whatever we want and, e.g. providing kind of configure- and execute-methods.

[dietzc]

Yes, we have to wrap them in KNIME specific commands. But do we want to expose all those methods to the user then? What's the benefit of using KNIME SciJava Commands then over standard KNIME nodes if users have to understand and implement configure, execute etc ...?

[hornm]

True. But we could provide an AbstractNodeCommand that heavily simplifies it (and is more familiar for future ImageJ2-developers) ... the direction of your 'easy-node' idea.

[dietzc]

Yep. But how would that be designed? I mean as soon as we require the user to implement configure and execute we require knowledge about KNIME development. Don't get me wrong, I have no idea whats the right solution here, I'm just trying exploring the possibilities or find out if it's even possible?

What we already have is that we can go 1row-1-ImageJTable (which is backed by a KNIME table of course). Maybe thats the way to go?! However, there we would need a simple configure which gives us the spec of the outgoing table.

[hornm]

Got the problem, I think. So essentially we'll need to provide a KNIME-independent Table interface (e.g. that returns its spec as a List of classes and is itself an Iterable<List<Row>>)? The current ImageJ Table interface seems very limited and only allows Double values!?

[dietzc]

The https://github.com/imagej/imagej-common/blob/master/src/main/java/net/imagej/table/Table.java Table is as generic as possible. We would require to know the outspec of the node. We could add a method which returns a spec as primitive java types? Then the super-class or some service could create a Table which is backed/implemented with a BufferedDataTable. However, then we will quickly run into generic problems RandomAccessibleInterval<T> vs. RandomAccessibleInterval<LabelingType<L>> if we only define our spec via *.class. This is the nice thing about having the parameters of the Command define the spec: Here we can get the generics...

[hornm]

Understand. But isn't there the same problem with the ops-matching and Curtis has a solution for that?

[dietzc]

Yes, you are right. Maybe this will help us a lot!