Link to multiple APIs

[MartinSchobben]

I guess this is more of an thought on the future of rirods. It was stimulated by discussing this R package: https://github.com/jspijker/ricmd made by @jspijker. Would there be a benefit of implementing interfaces to multiple iRODS APIs under a unified R package?

I would then envision a generalized rirods/ricmd (R) interface with multiple plugins for linking to the HTTP, Python, ... APIs, respectively, based on availability and user preferences. In this thought experiment some heuristics would figure out which API is available.

@jspijker, is your package still in use at the RIVM? And are you still considering to submit to CRAN?

[trel]

So this pure-R package would depend on different other ways to get to iRODS...

Curious / Interesting...

From https://irods.org/clients/ ... possible options...

• R -> HTTP -> iRODS (coming soon in update to use the new iRODS HTTP API #41)
• R -> iRODS (direct, would have to implement the iRODS protocol in pure-R)
• R -> Python -> iRODS (via https://github.com/irods/python-irodsclient)
• R -> Go -> iRODS (via https://github.com/cyverse/go-irodsclient)
• R -> S3 -> iRODS (via https://github.com/irods/irods_client_s3_api)

[jspijker]

The ricmd package was used during a pilot project with iRODS. It was a 'quick fix' to get an R interface for our iRODS setup and worked fine. However, it still has some quirks (mainly about authentication) ,search queries are not implemented yet and documentation and testing is site specific. For us, the question was if we should maintain our own package or use/contribute to a package which is (somewhat?) supported by the iRODS consortium. We prefer the latter, since this kind of package development is not our core business.

So I'm a bit uncertain what to do with the ricmd package. If the rirods package fulfills our needs, then there is no use case for us. However, the ricmd package can still be a viable option for other cases were no HTTP API is available, but then it needs some further development before we can submit it to CRAN (which I don't foresee, unless we have a use case)

[MartinSchobben]

If such use cases exist, a common R interface with plugin connectors could be beneficial. Instead of multiple R packages each with their own way of talking to iRODS. Maybe this is a pipe dream, or, at a minimum, something for a package version far in the future.

[trel]

It seems having a direct-to-iRODS-protocol option may remain viable for a while as long as an instance of the HTTP API is not available for a particular iRODS Zone.

From a maintenance perspective - a single package is preferred, of course. And we're working to make the HTTP API as easy as possible to deploy and manage (while also full-featured and consistent).

[montesmariana]

If we could have a direct-to-iRODS protocol it would not be necessary to connect via other clients as well, right? Or would there be benefits to using multiple connectors?

The better the HTTP API, the more likely that different iRODS instances will have it installed, but a direct communication would mean no installations other than rirods itself, no?

[MartinSchobben]

If we could have a direct-to-iRODS protocol it would not be necessary to connect via other clients as well, right? Or would there be benefits to using multiple connectors?

I think HTTP will always be a benefit for remote access. Also proper tools exist for HTTP APIs and associated test to make it compliant with CRAN. Come to think of it, the system requirement of having to have iRODS next to the R package will make it hard to pass CRAN checks. This was the issue with the old rirods package.

[montesmariana]

Ok, thank you. I have learned something new :)

[MartinSchobben]

Unless one places a vendor/copy of iRODS within an R Package. Like for the R package curl .

[trel]

Oh.

Initial reaction is that vendoring iRODS is NOT a good idea. Too many moving parts and would always be 'behind / stale'.