Project status?

[Simon]

Hi Chris, I have been playing once again with the ruby-dicom library and once again I'm impressed by how understandable and easy to use it is. 

I am a convinced believer in ruby, and I am convinced that there can be a stronger presence for the language in medical imaging, and your library would sit in the middle of that. My concern is that the project seems to be stalled somewhat, and I assume it's because of your time constraints.

The library is quite mature for many purposes, but there are some outstanding issues that would need to be addressed before one can commit to it as the basis for more 'enterprise-y' projects, in particular some regarding to memory management and concurrency for network communications.

I really, very badly want to use the library for more projects, but my coding skills are insufficient to fix these low level issues and help maintain it.

So I wanted to ask, what are your thoughts on the future of the project? Are you aware of anyone that may help out with maintenance? If you could identify specific areas where you need assistance, I could help fund a bounty for those critical issues or even see if we can hire a freelancer to assist you for a period of time or specific tasks. 

Please don't take this as a criticism of your availability for maintaining the library. On the contrary, I would love to help you find a way to continue it's development, under your guidance.

Cheers, and thanks again for an awesome, fun library!

Simon

Simon Rascovsky MD, M.Sc

[Christoffer Lervåg]

Hello Simon

Thank you for your thoughtful feedback. There hasn't been much buzz around the ruby-dicom library this last year, so its great to hear that people are still finding it useful. Actually, and this is somewhat of a strange coincidence, I just stumbled upon a publication which you have contributed to a couple of days ago: Open-Source, Web-Based Dashboard Components for DICOM Connectivity (Journal of digital imaging). Congratulations!

Regarding ruby-dicom development, I'll admit there hasnt been much happening since summer 2014 (the release of version 0.9.6). This is not because I don't have any further plans for ruby-dicom, its rather that I've been somewhat busy with non-dicom related projects. However, these last couple of weeks, I've actually pushed a few commits, and Im somewhat hopeful that I can manage to dedicate some time this spring.

My big plan for a ruby-dicom 1.0 milestone was to split up the network code in a separate gem, and rewrite this more elegantly and efficiently using the bindata gem for reading/writing binary data and Celluloid:IO for handling network communication with concurrency and improved performance. This is a somewhat big undertaking, and it simply stranded when I found myself lacking in available time. I still would like for this to succeed, but Im not asking anyone to hold their breaths waiting for it.

Less ambitiously, I would also like to work towards a 0.9.7 release. This would only contain small bug fixes and improvements, and should be quite possible to push out in the somewhat near future.

Im definitely not opposed to having people help out with our ruby-dicom issues. We've had quite a few commits by various people over the years, improving ruby-dicom in various ways, and such outside help is always welcome.

Where I think we should start out however, is to compile a list with issues, as specific as possible, that people would like to see improved in ruby-dicom. Then we can try to assess the amount of worked involved in fixing the various issues.

Best regards,

Christoffer

[Perry Horwich]

I just want to applaud these and other efforts. I too wish I could contribute more than I have. There is definitely space for this work in the Ruby environment, IMHO. There is a vanishingly small group of individuals who have access to DICOM clinical data in an IRB approved setting who also are granted 3rd party query privledges on a server of interest. I did for a while and your tool was by far the best option for my rails-centric project. Please push on when you can and evolve this gem along the path you have laid out. Separating network access strikes me as a worthy undertaking.

Many thanks again -

Perry