Hello! I am part of the KU Leuven team working on the iRODS implementation. We are very interested in an R client that could help increase iRODS adoption across R users in our institution. So, first of all, thank you for working on this package!
Given our interest and my experience with R, I looked into the rirods package. I understand it is still under development, and some of my observations can eventually be reported for bug fixes. However, I also have some questions that pertain to more profound design choices and the direction chosen for this package.
My most fundamental question is to what degree rirods is meant to align with other clients such as iCommands and the PRC. In particular, the names of the functions are the same as in iCommands, and this relationship was explicitly mentioned in the TRIRODS presentation. However, the {rirods} implementations of iput() and iget() behave in a different way, with a double functionality: transferring files (like in iCommands) and storing/reading R objects in RDS format. On the one hand, I think that the possibility to directly store objects in and read them from iRODS is a great feature, because it is already hard for users to wrap their head around the idea that they have to download the data to work on it and then upload the results. On the other, I'm not convinced that such a functionality should be covered by iput() and iget(), for two main reasons. First, because it then deviates from the iCommands behavior and can be confusing for users that are also familiar with iCommands. Second, and most importantly, because it makes the documentation of the function itself harder: the arguments are of different types, the return values are different... I think that the two behaviors, i.e. transferring files and saving/reading R objects, are different enough that they warrant separate functions, e.g. ireadrds() and isaverds(), or maybe iload() and isave(). This would have the additional consequence of setting apart this rirods-specific functionality from the common ground with iCommands, making it more clear and highlighting what {rirods} in particular brings to the table. Moreover, using different functions can make the choice more clear to the users: between interacting directly with iRODS but with an R-specific format, or using interoperable formats but going through the trouble of uploading and downloading.
A related question regards the limited range of file extensions that can be successfully transferred to iRODS via rirods. Is that a limitation of the API or a {rirods} choice, and what is the reasoning behind it?
Again, thanks for working on the package. I have a few notes that can become issues on the repository, but for now our main concern is the principle of the package: is the goal to mimic iCommands as much as possible while additionally offering the option to communicate directly with iRODS, or is the direct communication and storage in RDS format a priority, as suggested by the documentation and the iput() and iget()behaviors?
Kind regards,
Mariana
--
--
The Integrated Rule-Oriented Data System (iRODS) - https://irods.org
iROD-Chat: http://groups.google.com/group/iROD-Chat
---
You received this message because you are subscribed to the Google Groups "iRODS-Chat" group.
To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/irod-chat/b7a0de79-3cd8-432f-9ebc-6576329055e5n%40googlegroups.com.