hi jukka

> On Wed, Oct 24, 2012 at 11:01 AM, Angela Schreiber<anchela@adobe.com>  wrote:
>> basically i don't care how we implement it. but i think it's
>> crucial that we have the ability to control it... immediately
>> persisting binary-values without being able to enforce any kind
>> of validation or permission checks and ultimately reverting back
>> the changes is IMO not acceptable.
>
> What kind of validation or permission checks should/could be applied
> at that point?

it's not only about permissions... i just prevent us from
running into similar security issues we are having with the
version store in jackrabbit.
that's why i feel it's important that we define a life-cycle
for the items stored in the separate binary-store. this includes
questions like:

- 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?
- how do we deal with binaries that are not associated with an
   existing property? are they accessible somewhere/somehow? and if
   so by whom?
- 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?
- 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?

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