JRuby, ProteomeCommons.org IO

[Simon Chiang]

I keep seeing a lot of really, really tempting libraries in Java.
Take a look at this:

http://proteomecommons.org/current/531/

Have used this IO framework before? It suggests it allows you to read/
write RAW files (which up to now I think you only can do with the
extract_msn utility, only available on Windows, and only if you own
Xcalibur).

What I want to look into is packaging up JRuby + Tap as a .jar file.
That way you could get cross-platform access to some of these
libraries using Tap, and still have an easy install path.

[John Prince]

Yeah, I've looked at this libarary (and code) a few times.  It is a very nice library indeed. 

[NOTE: when I look at the .RAW file section, I don't see write support.  It looks to me that they only use the readw.exe... maybe I missed something]

At the end of the day, we probably do want to wrap the low level IO type stuff using this library or proteomewizard (pwiz) underneath, although there is still merit to just writing it in ruby (i.e., no outside dependencies).  It is a very tough call.

Here's my initial summary:

jruby + proteomecommons IO
-------------------------------------------
Pros:
1. easier to wrap java libraries in jruby
2. can send out one (or a few) .jar file that anyone can use without even installing jruby
3. a lot of nice code has been written for mass spec proteomics in Java (e.g., msInspect)

Cons:
1. Doesn't seem to be as up to date as pwiz
2. Doesn't support mzML (yet)
3. For extending to numeric analyses: spotty support for numeric manipulations in java; locked out of mri-ruby extensions (narray, gsl, svd, etc.)

ruby + pwiz
----------------
Pros:
1. the only platform supporting mzML currently
2. very robust and up-to-date
3. If we used FFI we could support all ruby VM's

Cons:
1. no one has been able to successfully SWIG it yet (not easy to wrap)
2. maybe not as much support for different conversions as proteomecommons IO (not sure on this).

plain ruby
--------------
Pros:
1. We control the code

Cons:
1. Often much slower
2. We have to write the code
3. We can't support as much


At the end of the day, if it is not too hard to wrap up proteome commons IO with jruby and tap, why not?  Maybe it could coexist with the other solutions?  (Do you have a jtap/jrap?)  At the very least, this would provide any user a very simple way to convert to formats that the mspire libraries could support (in whatever way works best).  Yeah, the more I think about it, the more this seems like a very good approach.

--John