Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.212.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5087C335.5060009@adobe.com>
References: <20121024073303.643D42388A29@eris.apache.org>
 <50879C9A.2080400@apache.org>
 <5087A5CF.20807@adobe.com> <5087A9A2.8070408@apache.org>
 <5087AE81.3090805@adobe.com>
 <CAOFYJNbfh3HQcRG3JYxwT7k4H49HYYcNkRMvntEZyvc6xMzjTQ@mail.gmail.com>
 <5087C335.5060009@adobe.com>
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Wed, 24 Oct 2012 13:32:09 +0200
Message-ID: 
 <CAOFYJNbKvCcqroTxuNyZ2kx7a6z+QKLOBgLgROdXEzATrDPo0A@mail.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)
To: oak-dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Hi,

On Wed, Oct 24, 2012 at 12:30 PM, Angela Schreiber <anchela@adobe.com> wrote:
> - is the content ID of those binaries exposed somewhere?

IMO it shouldn't be exposed to clients.

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

No, not beyond the session that created the binary.

> - how is the http-binding of such an binary?

A remote client should only be able to read a binary through the
containing property. The access controls on that property limit who
can access the 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?

Such binaries should only be accessible by the session that created them.

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

No.

> - can we prevent some sessions from writing to the binary-store
>   altogehter? if we can't what are the implications?

I guess we could, though I think the easiest way to do that would be
to have some special "upload binary" permission that's granted by
default but can be explicitly denied for a particular user or a
session.

> - 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?

One could always trigger a new garbage collection run. Alternatively,
if we modify the MicroKernel API accordingly, it could be possible for
the backend implementation to tie new binaries to the sessions that
created them so that when the session is closed any binaries that
didn't get added to the content tree could be automatically released.

BR,

Jukka Zitting