jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller" <thomas.tom.muel...@gmail.com>
Subject Re: [jira] Commented: (JCR-680) Improve the Value implementation
Date Fri, 22 Dec 2006 13:46:55 GMT
Hi,

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

> >   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?
I just think this is / would be quite a limitation for JCR-RMI. I'm
not sure about the use case for JCR-RMI and how long it is here to
stay, maybe it is OK if the functionality is / will be limited. 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)?

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

Thomas

Mime
View raw message