You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Alexander Chow <ac...@liferay.com> on 2009/05/28 10:38:24 UTC
CMIS Client API
Greetings All,
I am a bit new to the CMIS world and have been studying up on the
Chemistry code. Correct me if I am wrong, but, there does not seem to
be much in way of a CMIS client Java API as of yet. Is this correct?
In particular I was thinking in terms of Abdera extensions and the like.
Additionally, somebody mentioned they would be contributing the
SourceSense CMIS Portlet. Is that still in the plans?
One final question -- would it be possible for somebody to give a
quick introduction to the file hierarchy of the chemistry code (this
may warrant a separate thread)?
Cheers,
Alex
Re: CMIS Client API
Posted by David Nuescheler <da...@day.com>.
hi ugo,
thanks a lot for the response.
i think this is a good explanation, and i agree that we should not
contribute things if we are not sure that someone will take care
of its maintenance...
regards,
david
On Mon, Jun 8, 2009 at 9:48 AM, Ugo Cei<u....@sourcesense.com> wrote:
>
> On Jun 7, 2009, at 8:47 PM, David Nuescheler wrote:
>
>>> We discussed this internally and currently we do not think the portlet,
>>> as it is,
>>> would be a good addition to Chemistry. What we will do is use it as a
>>> testbed for
>>> client library implementation efforts, to which we indent to contribute.
>>
>> i liked the portlet quite a bit on the plugfest... just for my own
>> curiosity
>> what was the reasoning behind your decision?
>
>
> Basically I don't think the portlet, while being a good example of a CMIS
> client, is relevant to Chemistry in particular, as it stands. At the moment,
> it only uses a handful of constant definitions from Chemistry and uses
> Abdera for all of its protocol support, which doesn't seem to be the most
> likely direction Chemistry is going. So, if we were to contribute the
> portlet, it would have to be maintained to follow closely the development of
> Chemistry's own client-side code and I cannot promise that we will find the
> time for this. If this does not happen, the portlet will soon fall out of
> line with the rest of the code and be more of a liability than an asset.
>
> That said, if you and others feel otherwise, please start a vote to have it
> incuded in Chemistry. If people think it would be useful, we would be glad
> to donate it.
>
> In any case, the portlet is freely available at
> <https://dev.sourcesense.com/svn/alfresco/cmisdemo/> (we just need to
> declare the license before it can be used legally, but it will be done
> ASAP).
>
> Ugo
>
> --
> Ugo Cei
> Sourcesense - making sense of Open Source: http://www.sourcesense.com
>
>
--
David Nuescheler
Chief Technology Officer
mailto: david.nuescheler@day.com
web: http://www.day.com/ http://dev.day.com
twitter: @daysoftware
Re: CMIS Client API
Posted by Ugo Cei <u....@sourcesense.com>.
On Jun 7, 2009, at 8:47 PM, David Nuescheler wrote:
>> We discussed this internally and currently we do not think the
>> portlet, as it is,
>> would be a good addition to Chemistry. What we will do is use it as
>> a testbed for
>> client library implementation efforts, to which we indent to
>> contribute.
> i liked the portlet quite a bit on the plugfest... just for my own
> curiosity
> what was the reasoning behind your decision?
Basically I don't think the portlet, while being a good example of a
CMIS client, is relevant to Chemistry in particular, as it stands. At
the moment, it only uses a handful of constant definitions from
Chemistry and uses Abdera for all of its protocol support, which
doesn't seem to be the most likely direction Chemistry is going. So,
if we were to contribute the portlet, it would have to be maintained
to follow closely the development of Chemistry's own client-side code
and I cannot promise that we will find the time for this. If this does
not happen, the portlet will soon fall out of line with the rest of
the code and be more of a liability than an asset.
That said, if you and others feel otherwise, please start a vote to
have it incuded in Chemistry. If people think it would be useful, we
would be glad to donate it.
In any case, the portlet is freely available at <https://dev.sourcesense.com/svn/alfresco/cmisdemo/
> (we just need to declare the license before it can be used legally,
but it will be done ASAP).
Ugo
--
Ugo Cei
Sourcesense - making sense of Open Source: http://www.sourcesense.com
Re: CMIS Client API
Posted by David Nuescheler <da...@day.com>.
hi ugo,
> We discussed this internally and currently we do not think the portlet, as it is,
> would be a good addition to Chemistry. What we will do is use it as a testbed for
> client library implementation efforts, to which we indent to contribute.
i liked the portlet quite a bit on the plugfest... just for my own curiosity
what was the reasoning behind your decision?
regards,
david
Re: CMIS Client API
Posted by Ugo Cei <u....@sourcesense.com>.
[Apologies for the late reply and if this should appear twice, I'm
having problems with my mailer]
On May 28, 2009, at 1:16 PM, Alexander Chow wrote:
> On May 28, 2009, at 11:13 AM, Florent Guillaume wrote:
>>> Additionally, somebody mentioned they would be contributing the
>>> SourceSense CMIS Portlet. Is that still in the plans?
>
> Any comment on this?
We discussed this internally and currently we do not think the
portlet, as it is, would be a good addition to Chemistry. What we will
do is use it as a testbed for client library implementation efforts,
to which we indent to contribute.
Ugo
--
Ugo Cei
Sourcesense - making sense of Open Source: http://www.sourcesense.com
Re: CMIS Client API
Posted by Alexander Chow <ac...@liferay.com>.
On May 28, 2009, at 11:13 AM, Florent Guillaume wrote:
> On 28 May 2009, at 10:38, Alexander Chow wrote:
>> I am a bit new to the CMIS world and have been studying up on the
>> Chemistry code. Correct me if I am wrong, but, there does not seem
>> to be much in way of a CMIS client Java API as of yet. Is this
>> correct?
>
> You're right. I still plan on checking in the client code we have
> before the end of next week. It'll bridge the Chemistry APIs to an
> AtomPub client.
Thanks for the clarification.
>> In particular I was thinking in terms of Abdera extensions and the
>> like.
>
> Yes, except that Abdera may not be the best choice for a lightweight
> client that just needs to parse a bit of XML (it brings with it lots
> and lots of dependencies).
Makes sense. I was wondering that myself.
>> Additionally, somebody mentioned they would be contributing the
>> SourceSense CMIS Portlet. Is that still in the plans?
Any comment on this?
>> One final question -- would it be possible for somebody to give a
>> quick introduction to the file hierarchy of the chemistry code
>> (this may warrant a separate thread)?
>
> Separate thread it is.
Thanks!
> 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
Re: Java Client/Adbera (was: Re: CMIS Client API)
Posted by Ugo Cei <u....@sourcesense.com>.
On Jun 4, 2009, at 3:34 PM, Gabriele Columbro wrote:
> 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? :)
Speaking as an Abdera committer (though not very active) so take this
with a grain of salt.
Abdera is mostly nice and I would be sad if we decided not to use it,
however:
1. Not very active at the moment: basically it's just James working on
it and release 1.0 is long overdue (yes, you can blame me, lazy
committer, as well for this)
2. It has a bit of a FS (Flexibility Syndrome) with it's support for
pluggin different parsers/OM implementations.
3. Axiom, as you say, might be heavyweight. There has also been some
discussion on the mailing list abouth ditching Axiom.
Still it's got a decent OM interface and first-class support for IRIs
and I18N. Never had problems with the client implementation, also.
So I'm thinking that we might want to reuse the existing interfaces,
but provide a "lightweight" implementation for them. In time, we could
contribute our experience as feedback to Abdera and help design its
next version.
We should also strive to reuse the i18n stuff and the client stuff
too, which only depends on the interfaces, AFAIK.
Just my 0,02€
Ugo
--
Ugo Cei
Sourcesense - making sense of Open Source: http://www.sourcesense.com
Re: Java Client/Adbera
Posted by Florent Guillaume <fg...@nuxeo.com>.
On 4 Jun 2009, at 16:25, Florent Guillaume wrote:
> 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.
FYI the initial client code has been committed. This is quite
preliminary (just compiles but hasn't been tested yet), it'll need
some refactoring to work properly -- but you 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
Re: Java Client/Adbera (was: Re: CMIS Client API)
Posted by Bogdan Stefanescu <bs...@nuxeo.com>.
Hi all,
I will add more about the reasons on why the existing atom pub client
is not using Abdera.
As Florent said, the existing client was written in a hurry for a
client and it was not aligned yet with last chemistry API.
The objective was to build a very responsive rich client (based on
eclipse RCP framework) to be used to view/edit/publish stories by
people writing news.
Here are two requirements on the application (to have an idea about
the application constraints - e.g. performance / memory /
responsiveness constraints):
- People should be able to fetch news raw text (by using atom client),
create / edit news and publish them as faster as possible (several
second to create and publish a news)
- The application should display many views on remote feeds (loaded
using the atom client)
- Feed views must be refreshed in a 2 seconds interval.
Initially, I started using abdera but for several reasons (that I
explain below) I decided that it was not appropriate for the type of
application I wanted to build.
So, lets see how can we use abdera to build a chemistry object model
implementation for an atom client. We have 2 choices:
1. Either you wrap abdera objects in your own chemistry objects
2. Either you use abdera to parse the feed and build your chemistry
objects that are totally detached from abdera objects.
Let discuss both of these 2 approaches. I will start with the worst one.
1. Wrap abdera objects in chemistry object
This was my first approach. Here are the pros/cons:
Pros:
- Simplify a bit the implementation of the chemistry model - atom
validation included. No need to use Stax (or SAX) code to read your
objects from the remote feed.
In fact the simplification added by abdera is relative. You still
need to write code to parse your CMIS objects from abdera DOM.
Feed and entry parsing are anyway not complicated (atom is a nice
and simple format).
So the only thing abdera is really providing is atom validation and
an atom aware XML DOM. The rest should be implemented anyway (like the
CMIS Object parsing from the abdera DOM).
If you don't want atom validation then using another XML DOM library
will be the same from chemistry code perspective - where you need to
parse the CMIS object.
Here is a link to benchmarks on several XML DOM parsers including
AXIOM (the one used by Abdera):
http://www.xml.com/lpt/a/1703
Cons:
- Add to your application many extra dependencies (If I remember well
3 or 4 abdera JARs + 2 axiom JARs)
- Your CMIS objects will be larger (embed Abdera objects which
contains additional data not used by the CMIS code).
- Debug is difficult.
An annoying side effect is that debug becomes difficult. When you are
introspecting CMIS objects (that wraps abdera objects) you will need
to introspect abdera objects that are based on AXIOM model which is a
lazy DOM model (it is reading XML data into the DOM object only when
required). To understand what your object contain you need to
understand the AXIOM model.
- A technical issue I had with AXIOM way of doing things.
I will describe it here:
As mentioned above, AXIOM is loading data from XML into the DOM only
at client demand. For example if the client don't need to access the
30th entry in the feed the data of that entry will not be read from
XML input stream.
This is a very interesting AXIOM feature that I like but this feature
has a side effect in my application case.
Because AXIOM read the input stream only at demand it requires to have
the input stream opened until you read all the data you want from the
stream.
This means if you close the stream before the UI is completely updated
you will have an exception like this one:
Exception in thread "main" org.apache.abdera.parser.ParseException:
java.lang.RuntimeException: [was class java.io.IOException] Stream
closed
at org.apache.abdera.parser.stax.FOMBuilder.next(FOMBuilder.java:260)
at
org
.apache
.axiom.om.impl.llom.OMElementImpl.getNextOMSibling(OMElementImpl.java:
265)
at
org
.apache
.axiom
.om
.impl
.traverse.OMChildrenQNameIterator.next(OMChildrenQNameIterator.java:93)
at
org
.apache
.abdera
.parser
.stax
.util.FOMElementIteratorWrapper.next(FOMElementIteratorWrapper.java:41)
at org.apache.abdera.parser.stax.util.FOMList.buffer(FOMList.java:74)
at org.apache.abdera.parser.stax.util.FOMList.size(FOMList.java:88)
at
org
.nuxeo
.chemistry
.client.app.test.TestAbderaConn.parseWithAbdera(TestAbderaConn.java:61)
at
org
.nuxeo
.chemistry.client.app.test.TestAbderaConn.main(TestAbderaConn.java:39)
Caused by: java.lang.RuntimeException: [was class java.io.IOException]
Stream closed
at
com
.ctc.wstx.util.ExceptionUtil.throwRuntimeException(ExceptionUtil.java:
18)
at com.ctc.wstx.sr.StreamScanner.throwLazyError(StreamScanner.java:706)
at
com
.ctc.wstx.sr.BasicStreamReader.safeFinishToken(BasicStreamReader.java:
3655)
at com.ctc.wstx.sr.BasicStreamReader.getText(BasicStreamReader.java:
809)
at
org
.apache
.axiom.om.impl.builder.StAXBuilder.createOMText(StAXBuilder.java:245)
at
org
.apache
.axiom.om.impl.builder.StAXBuilder.createOMText(StAXBuilder.java:216)
at
org
.apache.abdera.parser.stax.FOMBuilder.applyTextFilter(FOMBuilder.java:
158)
at org.apache.abdera.parser.stax.FOMBuilder.next(FOMBuilder.java:206)
... 7 more
And in order to have a responsive application you need to update a
feed refresh asynchronously from the UI thread. You cannot control
when the stream is closed and when the UI is completely loaded.
So, this cool feature of AXIOM makes the AXIOM DOM unusable (or
hardly usable) in live objects displayed in rich client applications.
Let's look at the second option of integrating abdera
2. Using Abdera to parse the feed and build your chemistry objects
that are totally detached from abdera objects.
Pros:
- Provides ATOM validation and ATOM oriented DOM objects.
- Easy way to parse feeds and CMIS objects using the high level Adbera
DOM.
- Efficient way of parsing the feed input stream due to "load on
demand" feature of AXIOM. (sections in the feed you are not interested
in will not be loaded in memory)
Cons:
- Extra dependencies required by the applications as mentioned above
(~6 extra JARs)
This is an acceptable approach. The only issue for me are the extra
dependencies. To parse an atom feed you need 6 jars!?
It's true that for a chemistry client - parsing the feed is not
interesting at all. The client code must concentrate on implementing
the chemistry model in an efficient way to be able to use that client
in both simple administration applications and highly responsive rich
client applications.
My problem is that correctly parsing an atom feed with the focus on
CMIS objects can be done using Stax in a very efficient way and only
by writing several classes (no more than 10).
So after thinking more on this I also envisaged to use only AXIOM.
(without abdera). With only 2 extra jars I am able to efficiently load
my feeds. But I lose the atom model.
Anyway finally I realized that by only writing a few helper classes
over Stax I am able to do a more high level parsing in the style AXIOM
is doing - so I adopted this extreme approach. :)
May be my lists with pros and cons is not complete - but anyway it may
help you in adopting a solution.
Personally, If we absolutely want abdera I will vote for solution 2.
since 1. is not acceptable for my use cases.
If Abdera is not required then we can either use AXIOM, either
directly use Stax API as in the current client.
Regards,
Bogdan
On 4 juin 09, at 16:25, Florent Guillaume wrote:
> 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
>
Re: Java Client/Adbera (was: Re: CMIS Client API)
Posted by Florent Guillaume <fg...@nuxeo.com>.
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
Re: Java Client/Adbera (was: Re: CMIS Client API)
Posted by Ugo Cei <ug...@apache.org>.
On Jun 4, 2009, at 3:34 PM, Gabriele Columbro wrote:
> 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? :)
Speaking as an Abdera committer (though not very active) so take this
with a grain of salt.
Abdera is mostly nice and I would be sad if we decided not to use it,
however:
1. Not very active at the moment: basically it's just James working on
it and release 1.0 is long overdue (yes, you can blame me, lazy
committer, as well for this)
2. It has a bit of a FS (Flexibility Syndrome) with it's support for
pluggin different parsers/OM implementations.
3. Axiom, as you say, might be heavyweight. There has also been some
discussion on the mailing list abouth ditching Axiom.
Still it's got a decent OM interface and first-class support for IRIs
and I18N. Never had problems with the client implementation, also.
So I'm thinking that we might want to reuse the existing interfaces,
but provide a "lightweight" implementation for them. In time, we could
contribute our experience as feedback to Abdera and help design its
next version.
We should also strive to reuse the i18n stuff and the client stuff
too, which only depends on the interfaces, AFAIK.
Just my 0,02€
Ugo
Java Client/Adbera (was: Re: CMIS Client API)
Posted by Gabriele Columbro <co...@gmail.com>.
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?),
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? :)
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
- In terms of maintenance overhead, I see good improvements if Abdera
is used both in the server (IIUC) and client part
- 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.
- 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
- 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?
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 ;)
Thanks a lot for any suggestion/direction/clarification.
Ciao!
Gab
[1] http://hg.nuxeo.org/sandbox/chemistry/rev/0056848cfe96
[2] http://hg.nuxeo.org/sandbox/chemistry/rev/553652caf667
[3] http://mail-archives.apache.org/mod_mbox/incubator-chemistry-dev/200905.mbox/%3C655345a70905070143y39bde1fcpd45d858500eb6bd8@mail.gmail.com%3E
[4] http://www.mail-archive.com/chemistry-dev@incubator.apache.org/msg00022.html
On May 28, 2009, at 12:13 PM, Florent Guillaume wrote:
> On 28 May 2009, at 10:38, Alexander Chow wrote:
>> I am a bit new to the CMIS world and have been studying up on the
>> Chemistry code. Correct me if I am wrong, but, there does not seem
>> to be much in way of a CMIS client Java API as of yet. Is this
>> correct?
>
> You're right. I still plan on checking in the client code we have
> before the end of next week. It'll bridge the Chemistry APIs to an
> AtomPub client.
>
>> In particular I was thinking in terms of Abdera extensions and the
>> like.
>
> Yes, except that Abdera may not be the best choice for a lightweight
> client that just needs to parse a bit of XML (it brings with it lots
> and lots of dependencies).
>
>> Additionally, somebody mentioned they would be contributing the
>> SourceSense CMIS Portlet. Is that still in the plans?
>>
>> One final question -- would it be possible for somebody to give a
>> quick introduction to the file hierarchy of the chemistry code
>> (this may warrant a separate thread)?
>
> Separate thread it is.
>
> 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
>
--
Eng. Gabriele Columbro
Alfresco Software, Ltd.
M: +31 (0)627 565 103
P: +39 320 161 28 46
D: +44 (0)1628 876 654
Skype: gabrielecolumbro
Blog: http://www.mindthegab.com
Re: CMIS Client API
Posted by Florent Guillaume <fg...@nuxeo.com>.
On 28 May 2009, at 10:38, Alexander Chow wrote:
> I am a bit new to the CMIS world and have been studying up on the
> Chemistry code. Correct me if I am wrong, but, there does not seem
> to be much in way of a CMIS client Java API as of yet. Is this
> correct?
You're right. I still plan on checking in the client code we have
before the end of next week. It'll bridge the Chemistry APIs to an
AtomPub client.
> In particular I was thinking in terms of Abdera extensions and the
> like.
Yes, except that Abdera may not be the best choice for a lightweight
client that just needs to parse a bit of XML (it brings with it lots
and lots of dependencies).
> Additionally, somebody mentioned they would be contributing the
> SourceSense CMIS Portlet. Is that still in the plans?
>
> One final question -- would it be possible for somebody to give a
> quick introduction to the file hierarchy of the chemistry code (this
> may warrant a separate thread)?
Separate thread it is.
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