Comments (9)
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.
from irods_client_library_rirods.
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 #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)
from irods_client_library_rirods.
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)
from irods_client_library_rirods.
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.
from irods_client_library_rirods.
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).
from irods_client_library_rirods.
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?
from irods_client_library_rirods.
Ok, thank you. I have learned something new :)
from irods_client_library_rirods.
Unless one places a vendor/copy of iRODS within an R Package. Like for the R package curl .
from irods_client_library_rirods.
Oh.
Initial reaction is that vendoring iRODS is NOT a good idea. Too many moving parts and would always be 'behind / stale'.
from irods_client_library_rirods.
Related Issues (20)
- proposal for iget and iput behavior HOT 7
- new ichksum function HOT 2
- iquery should not interpret GenQuery column names HOT 2
- new function: info HOT 1
- Authentication to try out the package HOT 20
- Document multiple operations in `imeta()`
- Metadata columns in wrong order when some item has no metadata
- Should `icd()` behave like `setwd()` but on iRODS? HOT 1
- Allow relative logical path in `ils()`
- Create dedicated GitHub workflows for the R-CMD check and HTTP snapshots
- iput/iget should not write temp files to disk before streaming to iRODS HOT 2
- CRAN review HOT 2
- To-do HOT 2
- new logo - spacing and color HOT 7
- update to use the new iRODS HTTP API HOT 5
- Pin irods REST (HTTP) API version to package version
- Release rirods 0.1.2 HOT 3
- Make GitHub repo more discoverable. HOT 3
- rirods 0.1.2 has no GitHub release HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from irods_client_library_rirods.