Task #853
Updated by Rob Nahf over 11 years ago
Currently the R client assumes it is getting a data object, and so the constructor for [[DataPackage]] [[DataPAckage]] adds the retrieved object to the [[DataObject]] data list. Instead, need to inspect the [[ObjectFormat]] of the incoming object form system metadata, and use this to determine how to construct the [[DataPackage]] (ie, where to store the retrieved content). Also, in some cases we may be able to use lazy loading to grab the new parts of the data package as needed -- ie, only download science metadata or data objects as needed by calls to [[DataPackage]] accessor methods. This might be based on the size of the object (fine to cache small objects).
Under the new design (ORE packaging), the behavior probably changes somewhat - given a pid, it needs to make sure the format of the pid is that of a ResourceMap (RDF/XML), and throw an exception if not so.
Lazy loading leads back to expanding the underlying Java libclient D1Object class to be able to represent the object bytes in a flexible manner - download should hold a "D1RemoteDataSource", for example.
Under the new design (ORE packaging), the behavior probably changes somewhat - given a pid, it needs to make sure the format of the pid is that of a ResourceMap (RDF/XML), and throw an exception if not so.
Lazy loading leads back to expanding the underlying Java libclient D1Object class to be able to represent the object bytes in a flexible manner - download should hold a "D1RemoteDataSource", for example.
