Mailing-List: contact chemistry-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: chemistry-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of uncled@day.com designates
 207.126.148.88 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <56C255F88C54014E92512ED3E7848F9404679781@MUCXGC1.opentext.net>
References: <56C255F88C54014E92512ED3E7848F9404679781@MUCXGC1.opentext.net>
Date: Tue, 15 Dec 2009 17:24:10 +0100
Message-ID: <1b0d43d00912150824p758a911em59efb8e16b7ab35d@mail.gmail.com>
Subject: Re: CMIS Implementation Experiences
From: David Nuescheler <david.nuescheler@day.com>
To: chemistry-dev <chemistry-dev@incubator.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Florian,

> I would like to foster the technical discussion between the Chemistry tea=
m and the
> people behind the OpenCMIS proposal. If you think this is inappropriate o=
n this list,
> please let me know.

thanks a lot for the input and thanks for starting the technical
conversation. i think this
is really appreciated...

...and this is perfectly appropriate for this list!

> In order to explain the rationale behind the OpenCMIS design I would like=
 to talk about
> some of the experiences that we made with CMIS client and server implemen=
tations.
> We also started with Abdera on the server side. It turned out to be more =
pain than joy.

i think in the absence of Dominique (who is on vacation) it is fair to
say that in our
initial implementations we also found that there were some extension points
that we had to use that made us feel like abdera was not exactly
designed to inject
cmis in a surgical operation.
that may have to do with cmis and its use of atompub, but i think i
agree with the
general sentiment...

> With a pure JAXB design we ran into compatibility issues. A good tradeoff=
 between
> efficiency, correctness and maintainability seems to be StAX with JAXB. O=
penCMIS
> handles all AtomPub related tags with StAX and all CMIS related data with=
 JAXB.
> The JAXB objects are not exposed to the application. They are just interi=
m objects.
> The same StAX/JAXB design should work on the server side as well. The
> effort to implement AtomPub is manageable. I've done this in my CMIS
> FileShare project.
sounds like a reasonable proposal to me. especially given your experience
advice would be very welcome.

> Another detail we learned is that implementing both bindings in parallel
> saves you a lot of refactoring later. Both CMIS bindings are really
> different. If you align your classes and flows to just one binding you
> might have to refactor a lot later =A0to make the other binding work smoo=
thly.
agreed. i think the chemistry focus on the atompub parts of the spec
was just a way to get started, rather than a long-term plan.

> We introduced type (and repository info) caching based on our
> experiences with applications using a CMIS library. Applications need
> type information all over the place and it is expensive to fetch them ove=
r
> and over again.
absolutely. we ran into the same situation with jcr remoting through
our spi layer in jackrabbit. luckily, jcr already anticipates such caching
layer and exposes explicit "refresh()" methods.

> From a library perspective one can argue that caching should be done a
> level above the library.
> From practical standpoint it would be nice if it is done once and right.
i would even argue that depending on the application you may cache on
the application in addition of the caching in the pure transport layer.
i think there is nothing wrong with a cache as long as the application has
a means to refresh/invalidate the cache... ideally this would be possible
for parts of the cache, per folder/document or similar...

> So we decided to put it into OpenCMIS. If an application doesn't want it,
> it can switch it off. The caching works implicitly.
i would say a refresh much like in a browser could give the application the
option to flush parts of the cache or even expose that to the user.
in many cases the user "knows" that something changed and having
something like a "refresh"-button in the browser can help.
in my experience it really saves you a lot of first support calls, since
if the user does not see what he wants to see, he just hits the refresh
button, but of course that's a concern of the application and not
of the cmis client.

> Whenever a type definitions runs through the library the data is
> cached or refreshed. CMIS provides no mechanism to detect
> type changes.
i think type changes happen infrequent enough, that it is not
an issue in the majority of the cases, especially if we
expose an explicit "refresh" of the cache delegated to
the app or the user.

> So there is a slight chance that the type cache holds outdated
> data. In an enterprise scenario (and that's what OpenCMIS is
> aiming at) type changes shouldn't happen often. They are
> usually interconnected with an update or re-deployment of the
> application. A paranoid application developer can switch off the
> cache (and accept the performance penalty) or clear the cache
> regularly (every hour or every five minutes or every 30 seconds...)
> or create a new session once a while.
...or let the user of the app decide. especially
webapp users are used to refresh buttons ;)

> Since sessions are bound to logins there is a regular exchange
> of sessions and therewith caches, anyway.
sounds good.

> Another aspect that we think is important are extensions. CMIS
> defines a lot of extension points and repositories will make use of
> it sooner or later. Application should be able to access and set
> extension data. Sure, it is against the idea of a standard but it will
> happen and the library should be prepared for that. The difficult
> part here is to make the binding invisible to the application since
> some extension points are very binding specific. Using JAXB in both
> bindings covers a lot but not everything. OpenCMIS has the
> infrastructure in place but is not perfect in this regard, yet.
i think extension points are very desirable particularly in something
that should be a framework for various implementations / users.
having said that, superfluous extension points always become
a maintenance and backwards compatibility issue in the future, when
we want to refactor things again, and are not sure if we break someones
extensions... so i think we should choose extension points based
on real-life scenarios, rather than on wild ideas ;)

i think we are a group that is broad enough here that we have enough
real-life use cases to come up with a good set of extension points
to start with.

> I hope that's the beginning of a fruitful conversation,
same here, very much so... thanks a lot for starting it.

regards,
david