Custom Binary property

[Mathieu Baudier <mb...@argeo.org>]

Hello,

is it possible to define custom implementations of a Binary property ?

I'm working on a repository which will index and reference files. Some
will be stored as regular Binary properties, but most will actually be
URL referencing either files or remote resources.
(in many case we need to store the data on the file system because
third party tools expect them there).

The nt:file / jcr:content abstractions fit quite well with that kind
of approach (since I can implement custom jcr:content instead of
nt:resource), but ideally I would like to use only the JCR API and
hide the fact that the actual is not stored in the repository.

Ideally I would have a Binary implementation that would retrieve the
URL from another property of the node and give access to the bytes,
wherever they actually are.

My current understanding is that it is not possible and that the
recommend way is rather to have an application layer on top of the
repository dealing with that.
This is just that I would have been happy to have WebDav and DavEx
access working "out of the box".

Thanks in advance for your comments or best practices on how to
address such requirements!

Mathieu

Re: Custom Binary property

[Alexander Klimetschek <ak...@adobe.com>]

On 03.06.11 15:36, "Mathieu Baudier" <mb...@argeo.org> wrote:
>is it possible to define custom implementations of a Binary property ?
>
>I'm working on a repository which will index and reference files. Some
>will be stored as regular Binary properties, but most will actually be
>URL referencing either files or remote resources.
>(in many case we need to store the data on the file system because
>third party tools expect them there).
>
>The nt:file / jcr:content abstractions fit quite well with that kind
>of approach (since I can implement custom jcr:content instead of
>nt:resource), but ideally I would like to use only the JCR API and
>hide the fact that the actual is not stored in the repository.

I think it is better to reflect that important difference in the content
and handle it on an application level. It is too much magic & also a lot
simpler for you to implement it, since you don't have to hook into
Jackrabbit's implementation.

I would have a separate node type extending from nt:hierarchyNode (e.g.
"my:externalFile") with a url property pointing to the external location.
The JCR spec has something similar already, nt:linkedFile [0], but it is
only for internal links (using a very strict REFERENCE property). Or you
use a custom nt:resource node type on the jcr:content level, as you
mention.

Of course this approach won't work with things working with standard
nt:file/nt:folder nodes, such as WebDAV. But I guess there will be many
features around that (e.g. caching the file, just retrieving the URL, but
not downloading it yet, etc.) which you want to be able to handle on the
application level.

[0] 
http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.7.11.3%20nt:link
edFile

Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel