hi tobi On Wed, Jun 17, 2009 at 11:12 PM, Tobias Bocanegra<tobias.bocane...@day.com> wrote: > hi, > the spec of JSR283 defines a new mixin node type: > > [mix:lastModified] mixin > - jcr:lastModified (DATE) protected? OPV? > - jcr:lastModifiedBy (STRING) protected? OPV? > > "This mixin node type can be used to provide standardized modification > information properties to a node. Since the properties are protected, > their values > are controlled by the repository, which should set them appropriately upon a > significant modification of the subgraph of a node with this mixin. What > constitutes a significant modification will depend on the semantics of > the various > parts of a node's subgraph and is implementation-dependent." > > Since the "protected" attributes are variant, we can implement them as we > wish. > i would like to have a "good" jcr:lastModified behavior that is > directly provided by the repository. > OTOH when dealing with files (nt:file) uploaded from a filesystem, it > probably makes sense to transport the last-modified of the original > file. > > we need to define: > 1) does jackrabbit support automatic jcr:lastModified computation ?
yes > 2) if yes, do we make it protected ? no > 3) what operations on which scope affect which jcr:lastModified properties i'd say all changes that trigger a nodestate modification of the mix:lastModified node. > 4) does changing the jcr:lastModified property trigger an observation event? yes cheers stefan > > at a first glance, i would say: > 1) yes, please support it > 2) no, keep it writable > 3) all changes (except versioning and import operations) in an > mix:lastModified aggregate affect it's last modified property. the > aggregate is defined as sub-tree below a mix:lastModified node, > without all other mix:lastModified sub-trees. > 4) don't know - probably not > > WDYT ? > regards, toby >
