Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of stefan.guggisberg@gmail.com
 designates 209.85.220.217 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=WlnCEB1rk/58d2KCCUooWU6gwBgDoKX5Ue/2+a3aSd1eYBdRtA9vQE77UsRWnWuyzm
         E+0yym6r1pSZl152FsljB6LdBnvnebkvKU1hNrKTqIsBQDnvh8FLCv7pKJ6eVPuk6USN
         Ib78OSRhnFu6t+ec4DP4kLuBbt5Sqjv5+vhSA=
MIME-Version: 1.0
In-Reply-To: <ffd6aaa90906171412s7fd9951dtfa923eddf2de6efe@mail.gmail.com>
References: <ffd6aaa90906171412s7fd9951dtfa923eddf2de6efe@mail.gmail.com>
Date: Thu, 18 Jun 2009 09:58:30 +0200
Message-ID: <90a8d1c00906180058w44e1f14dwe58dc28484f8892c@mail.gmail.com>
Subject: Re: behavior of jcr:lastModified in jackrabbit 2.0
From: Stefan Guggisberg <stefan.guggisberg@gmail.com>
To: dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

hi tobi

On Wed, Jun 17, 2009 at 11:12 PM, Tobias
Bocanegra<tobias.bocanegra@day.com> wrote:
> hi,
> the spec of JSR283 defines a new mixin node type:
>
> [mix:lastModified] mixin
> =A0- jcr:lastModified (DATE) protected? OPV?
> =A0- 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 upo=
n 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 propertie=
s

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 eve=
nt?

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
>