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 this? > 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. <offtopic> 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? </offtopic> -- Best regards, Daniel Dekany
