Context and iDROP
This is an open, on-demand blog post and drafty software specification.
When I started at INCF, among other duties I inherited the supervision of an ambitious data sharing project called DataSpace. After going through its system architecture and python helper tools, it seems that the system follows good design principles.
Still, from the operational and usability sides, there is still plenty of room for improvement.
One of the most commonly mentioned drawbacks with the system has to do with how the data is presented to the researchers on the web. At the moment of writing this, an iDROP web interface is the canonical interface to access DataSpace for end users. The web client integrates well with the underlying iRODS infrastructure. One can perform common data operations plus manage its metadata attributes, as any commandline user would do with the underlying iRODS i-commands.
And even share (publish) a file as a (non-shortened, ugly) public link to share data with researchers:
OwnCloud development at INCF
I also took charge of leading an ongoing contract with OwnCloud Inc to completion on the first prototype of an iRODS-OwnCloud integration. After some weeks of testing, debugging, realizing about legacy PHP limitations and plenty of help from Chris Smith and a profficient OwnCloud core developer, a working proof of concept was put together with PRODS, a PHP-based iRODS client.
Today it works on both OwnCloud community and enterprise editions.
Despite it being a proof of concept having some serious performance issues, at least two scientific facilities have reported they are testing it already. Even if these are good news, it does need more work to be a robust solution. In the next lines, I will be describing what is needed to make it so, I will try to be as specific as possible.
But first, please have a look at the following GitHub pullrequest for some context on the current issues that need fixing: