jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: [jira] Commented: (JCR-680) Improve the Value implementation
Date Fri, 22 Dec 2006 22:48:13 GMT
Hi,

On 12/22/06, Thomas Mueller <thomas.tom.mueller@gmail.com> wrote:
> > The rationale for proposing a revolutionary rewrite rather than incrementally
> > improving the existing Value implementation is that the basic design of the
> > existing implementation doesn't allow easy extension or customization.
>
> What kind of extension / customization do you have in mind? I'm just
> curious... SPI?

SPI might be a good candidate, though I was especially thinking of
implementations where you'd rather use a custom adapter to an internal
value representation instead of one of the  existing the committed
value classes. The State pattern in the proposed implementation nicely
separates the internal value representation from the value state
behaviour, making it easy to implement custom value backends.

For example, I've been thinking about a simple SystemViewRepository
implementation that would expose a system view XML document through
the JCR API. It would make sense for such an implementation to
implement Values as adapters of the sv:value nodes in the DOM tree.

> > >   the stream data is materialized in memory during de-/serialization;
> > >   this renders it imo unusable for large streams.
> > Value serialization should never be used by Jackrabbit core, it's included for
> > other applications like JCR-RMI.
>
> So you mean the JCR-RMI would serialize streams? Does it do that now?

JCR-RMI currently uses temporary files for deserialized binary values.
I'm not too happy about that, a better approach would be to use a
RemoteInputStream to stream the data over the network on-demand.

> More generally, is there another way to (more or less) efficiently access a
> JCR repository remotely and store / read streams, and what is the plan
> for the future? Or is this the goal of the SPI project (from what I
> read, I'm not sure any more)?

I think the WebDAV server is already pretty good in that respect.
Implementing the JCR API on top of the WebDAV interface is one of the
goals of the SPI effort.

> > The goal of the default implementation is full semantic accuracy without extra
> > external dependencies (like to the file system)
>
> Currently I think that buffering really large (bigger than memory)
> streams to disk (temp file) on the client side is the easiest way to
> support them in a client / server environment. If you don't do that,
> then either you can't support large streams at all, or you need to
> implement special handling in the remote protocol. So you have the
> dependency there, and things get even more complicated and less
> modular compared to disk buffering. Just my opinion.

There are legitimate reasons to avoid temporary disk storage in a
general purpose component like the proposed Value implementation. For
example, you need to make sure that any temporary files are removed
when the referencing Value is no longer used and that file contents
can not be read by anyone else (in some cases not even by code in the
same JVM instance).

The limitation on memory use of serializing a binary value is
essentially the same as using Value.getString() on a binary value.
It's a useful feature in some cases and allows you to quickly
prototype things, but you need to add special handling to binary
values to make your application scale.

BR,

Jukka Zitting

Mime
View raw message