Hi, > I still don't believe that Oak is the right place to implement these >solutions.
What would be the right place then? The Oak user can store the path of the file as a string, but he would lose some features (garbage collection for example). >Every use case you outlined requires Oak to expose the location of the >binary objects in the underlying storage. I don't think every one. I think only UC1 and UC8 need it, read-only. If not already on the file system, we could copy the file to the file system (for example to the temp directory). UC2: already supported using references UC3: could be implemented with "fast random access reads" and changes in Tika. UC4: could we add a method "writeTo(WritableByteChannel target)"? UC5: The SHA-1 hash could be exposed if available, I don't see why not. Plus maybe UC1 or UC4. UC6: sounds like UC5 UC7: we would need details (how many writes, do we need a new identifier for each write operation,...). Can be implemented quite efficiently for the BlobStore implementations (MongoBlobStore / RDBBlobStore / FileBlobStore). >As soon as a file path, a file >descriptor or an S3 object ID traverses the boundary between Oak and its >clients, all bets are off. Well, we would need to define the exact contract, and maybe access rights. > is the correctness of Oak depending on the behaviour of the user? To some extend, this is already the case. Regards, Thomas
