Update chemistry IO nodes to support file system connections

Please could you update the chemistry reader and writer node to support file system connections? Currently, it’s not really possible to read or write these files from cloud storage, FTP sites etc.

I understand there’s already a ticket on this, but that was created at least two years ago. It’s frustrating that these have been left behind, given the importance of KNIME to pharma/biotech.

Hey @rsherhod,

Do you by any chance have the ticket number you are referring to?

I looked around and found a ticket most similar to your request dealing with chemistry reader and writer nodes under : AP-18265

I have went ahead and added a +1 to it.

Let me know if you are referring to another ticket,

1 Like

Apparently it was AP-13857. It was originally referenced in this 2022 thread: Using SDF Reader on remote FTP files

1 Like

Thanks for linking me the original ticket.

I do not have a specific timeline for you, but the team is aware of the issue.

I added a +1 to the ticket and linked this thread.


1 Like

Hi Richard,

(Hello again! It’s been a while that we have been in touch.)

I’ll try to add some explanation to this thread. Adding the file system port to the Chem/Bio IO nodes is on the list and we get are getting regularly reminded about this thanks to post like this but also customer feedback (and our internal life science team). So far it has been pushed out “yet another release” due to conflicting priorities and by knowing (and accepting) that we can take two steps at once when we convert these nodes to “modern dialogs”. These new dialogs have been added since version 5.0, and we are in the process of migrating more nodes. They have a cleaner look (no Swing anymore) + they will also allow us to use them via the browser. Version 5.3 will come with a bunch of more nodes, including some basic IO nodes (file / excel reader). We will migrate more nodes in the future (near future), including the chem nodes and then we also add the file system ports.

So far the plan has been to do them all at once. (However, if we deviate from that plan, in which order would you like to see them converted? I assume it starts with the Sdf Reader, but what comes next?)

Hope this helps,
– Bernd


Hi Bernd! Nice to hear from you. Yeah, it’s been a long time.

OK, that’s useful context. I can understand the desire to do the full reimplementation all at once, from a developer’s perspective. However, that’s only really a good thing for your life science customers if the reimplementation comes sooner rather than later. As a user, I can tolerate a clunky old GUI for a lot longer than I can do without file system support.

If the plan changes, then yeah I’d want the SDF Reader first, then the SDF Writer. After that, I’d prioritise any reader/writer that handles formats that can’t just be handled with normal readers, i.e. any formats where messing with new line and white space just wrecks the input data. That’s the problem with SDFs: reading them as rows of strings and trying to piece them together after just doesn’t seem to work.