Very helpful, thanks for your input! -- Rick Herrick Sr. Programmer/Analyst Neuroinformatics Research Group Washington University School of Medicine (314) 740-5961
On 11/5/14 10:46 AM, "Morrell Jacobs" <mjac...@maned.com> wrote: >Hi Rick, > >Oak is JackRabbit 3.0. My understanding is that it is a revamping / >modernization but the purpose / goal remains unchanged. You¹ve probably >seen this, but you can read more here<http://jackrabbit.apache.org/oak/>. > > >Our use of JackRabbit started around 2.2 / 2.4 and we are currently using >2.8. The transitions between 2.x version have been fairly easy; I expect >the transition to 3.0 to be more involved, but we have not started our >investigated yet (it¹s scheduled for the next sprint). > >We have traditionally use SQL databases for backend storage, but do have >a major project using JackRabbit. We found these features compelling: > >* Strong hierarchy support - the data for this particular project >inherently hierarchical. >* Dynamic properties >* Ability to store file data at any point in the hierarchy > >We were also drawn to the features that come out of the box with >JackRabbit: user & security model, versioning, etc. We run JackRabbit >embedded within each process (web app & backend processes); the >clustering configuration took some effort to get right (we are still >tweaking it), but we have been successful. My impression is that many >people are using JackRabbit for projects where the number of reads vastly >exceeds the number writes (sounds like that might be true for you also), >but, for our project, reads & writes are on a close[er] scale. Overall >we¹ve been happy with JackRabbit. > > >If you have been using a file system, I think a JCR would be a good match >and give you additional control & features. If I were considering a new >project now, I would look at Oak / JackRabbit 3.0; there¹s always >concerns about being close the leading edge, but that's where I would >start. > > >Background: I¹m a JackRabbit user, not contributor; I have, on occasion, >explored / debugged through the JackRabbit sources but am not an expert >on its inner workings. > >The folks working on Oak would be better able to describe its intent. > > >I hope that is helpful. > >Morrell Jacobs >Chief Software Architect >MEI >610 Old York Road, Suite 250 >Jenkintown, PA 19046 >Phone: 215-886-5662, ext. 252 >Fax: 215-886-5681 >http://www.maned.com >E-mail: mjac...@maned.com<mailto:mjac...@maned.com> >AOL IM: MorrellMEI > >Have you seen Nervous Pixel, MEI's creative services division? >www.nervouspixel.com<http://www.nervouspixel.com/> > > > >On Nov 5, 2014, at 9:14 AM, Herrick, Rick ><herri...@mir.wustl.edu<mailto:herri...@mir.wustl.edu>> wrote: > >We're in the process of working on an archive management system for our >medical imaging data platform (XNAT, http://www.xnat.org). Currently we >just manage files on the hosting file system, with all the issues that >implies. We've been considering using Jackrabbit to manage all of the >data resources (MRI, CT, PET and similar imaging data, synthetic data >from processing and analysis pipelines, research subject data, etc.), but >we have a few concerns. > >There doesn't seem to have been too much activity on this list, most of >the articles on the Jackrabbit articles page are from 2011 and earlier, >and most of the Jackrabbit news is actually about Oak. > >So is Jackrabbit still an on-going and supported platform? Should we be >looking at Oak instead? Basically we don't want to embark on a full-blown >development effort on something that may not be maintained. Or is just >that, because this is a back-end technology, there's just not that much >traffic and that's actually a GOOD thing (i.e. it's basically done and it >works and no one complains)? > >Any thoughts on this would be very helpful and greatly appreciated. >Thanks! > >-- >Rick Herrick >Sr. Programmer/Analyst >Neuroinformatics Research Group >Washington University School of Medicine >(314) 740-5961 > >________________________________ > >The material in this message is private and may contain Protected >Healthcare Information (PHI). If you are not the intended recipient, be >advised that any unauthorized use, disclosure, copying or the taking of >any action in reliance on the contents of this information is strictly >prohibited. If you have received this email in error, please immediately >notify the sender via telephone or return mail. > ________________________________ The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.
