Hey Chris, Thanks for your reply :)
>Or does that totally break the OODT model? It probably does... > > Nope doesn’t break the model at all - the Product with structure > ProductStructure.HIERARCHICAL works fine with this - data transfers > work fine - metadata retrieval works fine (try ingesting a directory), > and other things work fine too. > > However, I would seriously advise *against* using this model ^_^ > Mostly b/c no one really does it that way - and the code isn’t actively > being developed and maintained. At one point I thought it would be a > great thing to support and the last I heard of someone using this structure > natively was OCO from 2007/2008 (a NASA mission). > Thanks Chris. That confirms what I was thinking. I think I'll just keep it simple. >Also - does anyone store data on tape library and index it with OODT. I'm > >talking basic tar on a tape. This obviously breaks the file retrieval, if > >used, but I'm thinking of how this could be included in the OODT framework > >and maybe develop some methods. > > Well yep we do this - one way to do would be to add a > TapeBasedDataTransferer, > and/or utilities to handle waiting for data e.g., from Tape. You could also > use the InPlaceDataTransferer, and then come up with a Versioner that > easily > supports having Tape-based URIs. > Great! Thats where I'm heading :). How did you guys handle the URI's for tapes? I'm basically just using the the tape name - dataStoreReference = tape://MK0001L6 Cheers, Tom
