This proposal introduces a huge leak of abstractions and has deep security implications.
I guess that the reason for this proposal is that some users of Oak would like to perform some operations on binaries in a more performant way by leveraging the way those binaries are stored. If this is the case, I suggest those users to evaluate an applicative solution implemented on top of the JCR API. If a user needs to store some important binary data (files, images, etc.) in an S3 bucket or on the file system for performance reasons, this shouldn't affect how Oak handles blobs internally. If some assets are of special interest for the user, then the user should bypass Oak and take care of the storage of those assets directly. Oak can be used to store *references* to those assets, that can be used in user code to manipulate the assets in his own business logic. If the scenario I outlined is not what inspired this proposal, I would like to know more about the reasons why this proposal was brought up. Which problems are we going to solve with this API? Is there a more concrete use case that we can use as a driving example? 2016-05-05 10:06 GMT+02:00 Davide Giannella <[email protected]>: > On 04/05/2016 17:37, Ian Boston wrote: > > Hi, > > If the File or URL is writable, will writing to the location cause issues > > for Oak ? > > IIRC some Oak DS implementations use a digest of the content to determine > > the location in the DS, so changing the content via Oak will change the > > location, but changing the content via the File or URL wont. If I didn't > > remember correctly, then ignore the concern. Fully supportive of the > > approach, as a consumer of Oak. The locations will certainly probably > leak > > outside the context of an Oak session so the API contract should make it > > clear that the code using a direct location needs to behave responsibly. > > > > It's a reasonable concern and I'm not in the details of the > implementation. It's worth to keep in mind though and remember if we > want to adapt to URL or File that maybe we'll have to come up with some > sort of read-only version of such. > > For the File class, IIRC, we could force/use the setReadOnly(), > setWritable() methods. I remember those to be quite expensive in time > though. > > Davide > > >
