Generic Nodes

[kerner1000]

Currently, we follow the "one processor, one node" approach. Technically, it is possible to automatically generate from all OpenChrom processors according KNIME nodes. This has a few disadvantages:

1. We loose control over which processors will be available as KNIME knodes.
2. We cannot remove processors anymore due to backward compatibility (if this becomes part of the community extensions).
3. Users might find it confusing if it is not perfectly clear which importer actually reads the data. The advantages are clear:
4. Much less KNIME code
5. All OpenChrom processors automatically available as KNIME nodes.

[kerner1000]

Blocked by https://github.com/eclipse/chemclipse/issues/28.

[laeubi]

afaik we must only support past KNIME release, this does not mean we can't change anything. Beside that I don't think that users really like to choose the right importer, the just want to read "a chromatogram file". The current approach also adds a direct dependency to the processors itself and massive maintenance work must be done to keep things in sync and a lot of duplicate work has to be done. also its much more convenient to have a hand full of processors instead of hundreds to choose from as we can nicely categorize them (comparable to the Batch/Method editing UI).

[laeubi]

Processors / Converters also carry descriptions already, if we need to improve the descriptions because of #6 and improve them directly in OpenChrom/Chemclipse this would benefit even more.

[eselmeister]

As far as I understood, OpenChrom nodes are created on-the-fly in KNIME, based on the Json annotations and the extension points we offer for data import, filter, peak detectors, ... . The aforementioned nodes are already categorized in the same way as in OpenChrom.

Am 15.10.19 um 20:20 schrieb Christoph Läubrich:

afaik we must only support past KNIME release, this does not mean we can't change anything. Beside that I don't think that users really like to choose the right importer, the just want to read "a chromatogram file". The current approach also adds a direct dependency to the processors itself and massive maintenance work must be done to keep things in sync and a lot of duplicate work has to be done. also its much more convenient to have a hand full of processors instead of hundreds to choose from as we can nicely categorize them (comparable to the Batch/Method editing UI).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenChrom/knimeconnector/issues/8?email_source=notifications&email_token=AAFHUTZPDHCFKMBAX34QNDDQOYCVLA5CNFSM4JBAEWIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBJXSBA#issuecomment-542341380, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFHUT3BV6QC3XI3TZC2UUDQOYCVLANCNFSM4JBAEWIA.

--

OpenChrom - the open source alternative for chromatography / mass spectrometry
Dr. Philip Wenig » Founder » philip.wenig@openchrom.net » http://www.openchrom.net

[laeubi]

maybe this was planed /prototyped once but is currently not available. Also instead of using the extension points directly using the processing API is more general, flexible and requres less dependencies.