> content repository core, because that's the part of the system that
> knows about everything happening with the repository, so it's probably
> the best place to keep the object mapping cache up to date.
1. A mapping tool included as part of the jcr spec or as optional feature of the implementation.
not sure. On the one hand it would make things easier. On the other hand, it would mix responsibilities. Maybe I'm old fashioned ;), but I feel attached to a mapping tool running on top of jcr. I'd like to be able to swap the mapping layer if I found a better implementation, just like I do now with orm tools.
> As it is "outside the scope of the specification", you don't even have
> Repositiry.OPTION_SYNCHRONOUS_OBSERVATION_SUPPORTED or something like
> that
2. Synchronous Observation.
hmm..., it would affect performance seriously depending on the number of remote clients.
> the specification should introduce nt:monitored (don't deal
> with the poor name choice for now...), that should mean that the node
> has these properties:
3. auto update properties.
I agree it would be useful. Maybe an autoUpdate property could be added to the Item definition. As the auto-create property creates a given property, the auto-update would update it. WDYT?
> I could use cache in front of JCR that caches
> the template objects, but how to ensue that the cache is in sync with
> the repository?
4. A multi-tiered cache.
I think it won't be difficult to build such a cache on top of the decorator layer proposed by jukka. see http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/188. It's not commited yet.
regards edgar
