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 Fri, 17 Aug 2007 21:14:12 GMT
"If you want to discuss a data model change, please be clear about it,
and stop discussing the API. What the API does depends on the data
model, not the other way around."

I think we've had this discussion in another thread already...

Anyway, I'm discussing the API. JCR is an API, not an implementation. Please
see:
  http://en.wikipedia.org/wiki/JSR-170
"*Content Repository API for Java* (*JCR*) is a specification for a Java
platform <http://en.wikipedia.org/wiki/Java_platform>
API<http://en.wikipedia.org/wiki/Application_Programming_Interface>for
accessing content
repositories<http://en.wikipedia.org/w/index.php?title=Content_repository&action=edit>in
a uniform manner. "

I don't care that there are 800+ implementations out there already for
content repository or the data models that each of the those implementations
uses. I'm sure that consideration was made for the implementations that
existed prior to the spec, but I'm also sure that not every one of those
implementations could easily accommodate conforming to the spec, and thats
why different levels were introduced.

In any case, its the mandated behavior of the new spec that I'm trying my
best to provide feedback on, which I'm actually hoping may improve it.

Regards,

Mark


On 8/16/07, Julian Reschke <julian.reschke@gmx.de> wrote:
>
> Mark Waschkowski wrote:
> > ...
> > Fair enough. However, look at it from the reverse point of view, what
> would
> > the impact to the users of the API be if setting a property to null
> DIDN'T
> > remove it (assuming there was a flag that could be set to toggle the
> > behavior on startup to deal with compatibility issues)? The existing
> > remove() function would then be used to remove properties when not
> desired,
> > instead of setting properties to null and having this side-effect. I
> believe
> > that the API would be more intuitive to most, if not all users, the
> > workarounds that we have developed wouldn't be required, and that nobody
> > ...
>
> Again:
>
> the thing that's being proposed is not an API change, but a data model
> change.
>
> If we stick with the current data model (which I'd support), then
> passing a null value can either cause an exception, or cause the
> property to be removed. I don't have a preference here, except for
> keeping compatibility with JSR-170.
>
> If you want to discuss a data model change, please be clear about it,
> and stop discussing the API. What the API does depends on the data
> model, not the other way around.
>
> Best regards, Julian
>
>


-- 
Best,

Mark Waschkowski

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message