jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael D├╝rig <mdue...@apache.org>
Subject Re: BlobFactory (was Re: svn commit: r1401571 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/api: BlobFactory.java Root.java)
Date Wed, 24 Oct 2012 08:41:06 GMT


On 24.10.12 9:24, Angela Schreiber wrote:
> hi michael
>
>>> + * TODO review again if we really need/want to expose that in the
>>> OAK API
>>
>> The consequences of not doing so is, that there is no way to create
>> blobs through the Oak API which are immediately streamed down to the
>> Microkernel.
>
> yes... i know :)
> don't get me wrong, i am not opposed to that in general.
> but there are some open issues associated with that, which i
> would like us to clarify before we finalize the API.

Since we have to address these issues anyway because we have the same 
problem with ValueFactory.createBinary(), I'd rather also keep a means 
for creating Blobs in the Oak API. Otherwise the API wouldn't be 
complete and other bindings would have to come up with their own plugins 
just to write binaries.

>
>>> + * TODO in particular exposing this interface (and Blob) requires
>>> additional thoughts on
>>> + * TODO - lifecycle of the factory,
>>> + * TODO - lifecycle of the Blob,
>>> + * TODO - access restrictions and how permissions are enforced on
>>> blob creation
>>> + * TODO - searchability, versioning and so forth
>>
>> All these TODOs also apply to the blobs which get created through the
>> ValueFactory in oak-jcr and this was already the case before the
>> refactorings of OAK-350.
>
> yes, that's correct... but it doesn't mean that we shouldn't
> think about the consequences of having such a feature.

Right. I just wanted to check whether there where considerations re. 
this earlier and what these where. But maybe the whole thing only came 
up through having the BlobFactory that explicitly in the API.


> what happens if the adding/changing a binary property fails due
> to lack of permissions or due to conflicts or value constraint
> violations or some other custom value-validation? i think that we
> need the ability to revert the changes made to the binary-store
> in such cases...
> if we don't have that ability everyone having a Root/ContentSession
> at hand (even if it was a read-only session) could dump any kind
> of binaries into the repository. that doesn't make sense to me
> and looks like a critical security issue... remember o.html? IMO
> it's that kind of troubles we are looking for when not having any
> means to control who and what is written to the binary store and
> not having the ability to revert changes if the overall commit
> fails.

Currently the data store garbage collector of the Microkernel cleans 
unreferenced binaries out after some time. If we want to have more 
explicit control of the life cycle for binaries, we'd need to have 
support for this from the Microkernel.

Michael

>
> kind regards
> angela

Mime
View raw message