jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mic...@gmail.com>
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 12:09:29 GMT

On 24.10.12 11:30, Angela Schreiber wrote:

> - is the content ID of those binaries exposed somewhere?

> - is there an alternative way of accessing such an binary except
>    for regular property-access which was controlled by access control?

> - how is the http-binding of such an binary?
Only through a property.

> - how do we deal with binaries that are not associated with an
>    existing property? are they accessible somewhere/somehow? and if
>    so by whom?
Currently they will get garbage collected at some point. Until then they 
are only accessible when you knwo the corresponding binary ID. The 
binary ID lives and dies with the corresponding binary property.

> - is there a way of searching the binary-store by other means that
>    executing a regular jcr/oak search on the content tree?

> - can we prevent some sessions from writing to the binary-store
>    altogehter? if we can't what are the implications?
I guess we could. The only implication I see is that without this 
everyone with access to a Root instance can fill the binary store with 
garbage while without such an access control mechanism in place you 
could only do that when you also possess the necessary permission (which 
will be quite regularly the case since everyone who wants to create 
binary properties will have to have that permission).

> - is there way of reverting change made to the binary store without
>    having to wait for garbage collection? who would be in charge
>    of doing so? what was the interface to do that?
Currently not. This would require support from the Microkernel.


> it's this kind of questions that i have with respect to the binary
> store and which i would prefer us to have thought about before we
> have to deal with customer escalation.
> regards
> angela

View raw message