Hi Andy, Thanks for your question. My replies inline below:
> > I'd like to implement a new data transfer protocol in the file manager. > More specifically I'd like to be able to call the StorNext SAN API to move > large files with greater efficiency than native copy commands allow. > > Would the best approach be to create StorNextDataTransfer and > StorNextDataTransferFactory classes (implementing the appropriate > interfaces) and include my custom logic therein? +1, yep that's the way to go about it at least IMHO. > How would I instantiate my > custom solution? After you bake up your 2 classes (the transfer and the factory), package them up somehow (you could create a stornext-transfer MVN project) and then what you'd do is end up with a jar somehow (via Maven, or however) and then take that jar and drop it inside of filemgr/lib inside of your deployment directory. Then edit your filemgr/etc/filemgr.properties file and specify your data transfer factory (if you are doing FM server side transfer). If you are doing client transfer (via the crawler, the std ingester, or simply via the filemgr-client), then all you need to do is specify your data transfer factory and then specify the clientTransfer switch. Then after you've used your data transfer for a while and are confident in it, and if you are willing you could always contribute it back to OODT proper at Apache. This would depend on the licensing for whatever underlying library that you integrate (you can check http://www.apache.org/legal/resolved.html for that) and then you'd create a JIRA issue for it and attach a patch. Thanks and good luck Andy! Cheers, Chris > On Sat, Mar 19, 2011 at 12:36 PM, Andy Bauch <andy.ba...@gmail.com> wrote: > >> In the product server documentation it states that the service can >> "transform products from proprietary formats and into Internet standard >> formats or run other transformations, all without impacting local stores or >> operations." >> >> I was wondering what enabled this open-ended functionality. From what I >> can tell, the idea is that you simply create your own implementation of the >> QueryHandler interface and do all of the data fetching/transformation there. >> >> Is that the case? >> >> Thanks! >> >> -Andy >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
