jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <ddek...@freemail.hu>
Subject Re: Getting "custom" objects from the repository?
Date Sun, 17 Apr 2005 21:19:35 GMT
Sunday, April 17, 2005, 8:58:54 PM, Ben Pickering wrote:

>> sounds like we have with daniel and ben two volunteers to
>> implement a general purpose, scalable, distributed, transactional
>> cache with low network overhead as part of jackrabbit.
> Um, I'm not talking about anything like this...  I'm not even talking
> about adding any features to Jackrabbit or JCR or anything.  All I'm
> asking is, given that the majority of uses of content are likely to be
> more complex than just setValue()-getValue(), is there any scope for a
> pattern *on the client* (and *only* on the client, no caching, nothing
> special going over the connection, and using only the JCR API) that
> the expert group had in mind.  (Maybe the answer's 'no'?)
> Please don't think I underestimate (or even claim to have a broad
> knowledge of) the JCR use cases!

Well, I start to think that maybe the use case that this thread is about
was not considered. And *if* it really wasn't, then I really don't know
what to think... just how could that happen??? But we have David
Nuescheler (the JSR 170 Specification Lead) here, and I guess many more
from the JSR 170 Expert Group, so, just out of curious, what was with

> All I'm asking is, how do I write a program that talks to a repository
> where I can say Image.getColorDepth() rather than having to know the
> name of the property. Not hard... I don't have astronomical
> aspirations here... As I say in another thread, it's the APIs and only
> these that bother me, as someone who's going to have to work with JCR
> client libraries.
> Remember, *only the client*!  I'm a lazy client-side programmer -- how
> is my experience of working with a repository made easier?  Maybe I'm
> being a bit blue-sky here.

I guess the solution for the issue this thread is (originally) about
overlaps very much with the issue you are talking about, just we have
different main goals:

- You want more friendly, application specific API to reach the repository.
  Sure, I also want that, but for me it's not the show stopper problem.

- I want acceptable performance with caching the objects that are
  expensive to re-construct from the property values. (And I'm very
  certain that storing such objects in the content repository will be a
  very common demand... except if people just left JCR on such cases,
  since they can't do it with that.)

Now, when the 2nd (performance) issue is solved by this cache thing,
then your API issue is also solved (despite that I don't meant to solve
that with the cache, it automatically does that). Also, if you want to
get the repository content as application/whatever-framework specific
objects (as I understand you do), probably you will quickly find that
some of your application/whatever-framework specific objects are just to
expensive to be re-created for each repository query (ala Hibernate), so
you had to cache some of those objects.

And yes, I'm also talking about something that works on the client side.
The cache is on the client side, and it is maybe a totally application
specific cache (like the template cache for a template engine). Just I
have found that I can't implement this client side cache because JCR
doesn't give me anything I could build the cache synchronization on.


But really, just think about how strange it is... even if you use plain
simple files to store content, you have a last modification time which
is automatically updated. It's just such a basic thing for a repository,
independently of this caching issue. Hands up, who didn't have to use
file last modification times during his developer work? Now the
uuid+modificationCounter is basically the same, except that it is really
correct if you want cache synchronization and such. I mean, with last
modification times it can happen that you modify twice something within
the same second (or whatever the clock resolution is), or that you
replace a file with another different file, but their last modification
times happens to be the same. But anyway, independently of the cache
synchronization issue, I guess people will miss automatically maintained
last modification time also (automatically, so it doesn't mater with
what tool do you access the repository with). I don't mean last
modification time for all nodes, just a mixin type in JCR 1.1 like
tn:lastModificationTime, even made it optional feature, and then we will
see if users will prefer the JCR implementations that support it.

BTW, JSR 170-0.16.3 question: Why is the jcr:lastModified of nt:resource
is ignored from versioning?

Best regards,
 Daniel Dekany

View raw message