jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Waschkowski" <mwaschkow...@gmail.com>
Subject Re: 3.1.3.1 Removing Items
Date Mon, 23 Jul 2007 17:53:33 GMT
Hi Jukka,

Jukka said:
" but complaining about it doesn't really help anyone if you don't have an
idea of how to fix that"
The OP suggested a change to the spec, and I agree with Alexandru, a change
that makes the spec clearer makes it stronger.

Repeated here:
" === Proposal ==========================================

  * Setting property to NULL will set property value to NULL without any
side
effects, such as removing a property.

  * To remove a property we call: p.remove();

  ========================================================"

Jukka said:
"Note also that for an idea to have a reasonable chance of being accepted in
JCR 2.0, it *needs* to be backwards compatible."
As Alexandru stated, that door has already been opened with xpath and sql
for that matter because none of the querying is backward compatible with 1.0,
is it?

Best regards,

Mark


On 7/20/07, Alexandru Popescu ☀ <the.mindstorm.mailinglist@gmail.com> wrote:
>
> On 7/20/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> > Hi,
> >
> > Everyone, I don't think this thread is getting us anywhere at the
> moment.
> >
> > There are many cases (like setProperty(null)) where the JCR 1.0 API
> > could have been designed otherwise, but complaining about it doesn't
> > really help anyone if you don't have an idea of how to fix that.
> >
> > Note also that for an idea to have a reasonable chance of being
> > accepted in JCR 2.0, it *needs* to be backwards compatible. So for
> > example we can't just declare that setProperty(null) will start
> > throwing NullPointerExceptions, as that's bound to break a whole lot
> > of existing clients.
> >
> > Of course I'm all ears (and I believe the whole JSR 283 expert group
> > at jsr-283-comments@jcp.org is) for good suggestions where things
> > could be improved, but just complaining that a feature doesn't work
> > like you want or suggesting obviously incompatible changes doesn't
> > really get us anywhere.
> >
>
> Sorry Jukka, but I don't really feel we were complaining here, but
> rather describing the problem so that everybody has chance to see our
> reasoning. And the initial post started with the proposal.
>
> Now about the compatibility issue: considering that 2.0 is suggesting
> the removal of XPath we cannot talk about backward compatibility
> anymore. One more change at the API level and one that will make
> things clearer is the smart decission (remember we are not talking
> about a 1.1 spec, but about 2.0 which is already suggesting
> non-backward compatible changes).
>
> bests,
> ./alex
> --
> .w( the_mindstorm )p.
>
> > BR,
> >
> > Jukka Zitting
> >
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message