On 4 Jun 2009, at 15:34, Gabriele Columbro wrote:
G'day Chemicals,
as I finally found some time to spend on the mighty Chemistry, I was
able to go trough the ongoing mail threads and look a little bit
better at the status of the Chemistry codebase (with an eye on which
parts of Alfresco that may be suitable for contribution).
I would like to start working a bit on the client / TCK / build
automation part of the project, but, before discussing the details
with you guys and get into action, I saw a couple of open mail
threads (forwarded one and [4]) on a topic that can impact a lot the
way I can contribute to this project:
I'm talking about the implementation of the AtomPub Java Client.
As I understand Florent is working on the AtomPub Java Client and
IIUC it isn't going to be based on Abdera. Though I could not find
yet any code in SVN (@Florent: nor in the Nuxeo HG 'default' [1]
revision, am I pointing the right one or 'integrate-atom-pub' [2] is
the one to look at?),
Yes the code we have is in branch integrate-atompub-client in http://hg.nuxeo.org/sandbox/chemistry/
-- the old repo used before switching to Apache svn.
But as it happens I'm studying this code right now to adapt it to the
newest Chemistry API refactorings, and I'll commit code in svn before
tonight, although it may be nonfunctional and not very unit tested at
all :( This code was written in a hurry by Bogdan for a customer
(although we have the IP on it) and is not up to the standards I
expected of it, so don't hesitate to criticize it and discuss
refactorings.
so I was finally wondering:
1__ What's the state of the art of the AtomPub Java client impl?
What the dev's opinion on the usage of Abdera? Is that already been
discussed and I missed it? :)
No real discussion in these lists.
After having worked with Abdera for the server part, I've come to the
conclusion that it's a big library, rewrapping a lot of Axiom.
Also it's still very young, and not well designed for extensibility if
you stray from the simple "one feed with entries in it" model.
Bogdan, for the client part, decided to not use Abdera because one of
his goals was to allow it to be a small embedded library, so StAX was
all that was really needed. Abdera apparently is creating lots and
lots of objects and use lots of memory, when a simple StAX-based
parser gave him huge performance boosts.
There are a couple of reasons why I ask you guys suggestions/
clarifications on this topic:
- Adbera is the standard Apache Atom implementation and we can rely
on a good cooperation between Apache projects
Agreed, however note that working with SNAPSHOTs of other projects is
a headache in terms of release. So if we start modifying Abdera then
we'll have to think about how to release.
- In terms of maintenance overhead, I see good improvements if
Abdera is used both in the server (IIUC) and client part
Do you see any factoring between client and server beyond the Abdera
extensions, beyond the few ElementWrapper subclasses?
Note also that I have already started using Abdera's
ExtensibleElementWrapper in chemistry-atompub, however I don't
register them as an Abdera extension (I instantiate directly) because
Abdera extensions are global and I don't want to step on the toes of
any other code that would like to work with Chemistry but already uses
its own Abdera extension (like Alfresco). chemistry-atompub only has
the methods useful for the server though, not yet the client.
- In terms of dependencies explosion, I don't see a big deal in the
Abdera (client) chain of (runtime) dependencies, especially if you
consider that the (Java) client is going to be most likely to be
used for Java based Content Repositories (or custom applications)
integration and these are typically library-flooded applications
anyways.
I can't disagree with the fact that projects usually already use lots
of libraries, so what's one more. Note however that Abdera is huge,
abdera-core + abdera-i18n + abdera-parser are already at 900 Kb
(Mostly due to Unicode data in abdera-i18n by the way).
- Choosing for Abdera, may enable me to contribute the already
functional Abdera extension of Alfresco, so to give quite of a jump
start on the TCK/Client side
That's a good point.
BTW we also have an Abdera extension in yet another (older) CMIS
sandbox (http://hg.nuxeo.org/sandbox/nuxeo-cmis/file/tip/src/main/java/org/apache/abdera/ext/cmis/
) which could be used as well. If you contribute yours, I'll look at
merging useful things we may have into it (although Abdera extensions
are in fact rather simple).
- The usage of Abdera seems to be an enabler for contributions
already built on top of it (see Sourcesense CMIS portlet [3])
2__ Do you think the Abdera extension could be a valid contribution?
And in such a chase, would it belong to Chemistry or Abdera itself?
I would leave it in Chemistry until we consider it mature enough to be
moved to Abdera -- barring any dependency problems. This way we'll get
much more rapid turnaround in its update. It could move to Abdera once
CMIS 1.0 is released, for instance.
As I'm not sure what the status of Florent implementation and
particularly I don't want to waste any effort already done, and this
is actually my first interaction with the list,
so please forgive me if I'm missing some blatantly obvious point ;)
No problem, these are all worthwhile points.
My next steps are to study Bogdan's client code, and if I (or the
list) feel its inadequate the I'll scrap it to go back to a simple
Abdera-based implementation. I'll commit something tonight in svn so
that others can look at it.
Florent
--
Florent Guillaume, Head of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
