abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jun Yang <jyang...@gmail.com>
Subject Re: Abdera status and future
Date Wed, 06 May 2009 00:09:44 GMT
On Tue, May 5, 2009 at 1:32 PM, James M Snell <jasnell@gmail.com> wrote:

> Ok, so I've got a fix for the ant build pending commit... for some reason
> the svn.apache.org server is not responding right now so I will commit
> that as soon as possible.
> In the meantime, I'd like to discuss Abdera plans moving forward.
> I know the 1.0 release was voted on but was never actually cut. I'm going
> to try to get that pushed out in the next week or two.
> Moving foward, there are a number of changes and refactorings I'd like to
> look at:
> 1. Axiom does a good job of handling the XML infoset stuff Abdera needs but
> it brings along with it a number of dependencies and extra stuff that we
> just don't need (like all the SOAP stuff). In an ideal world, Abdera would
> be entirely self-contained.  I would like to start investigating what it
> would take to remove the Axiom dependency from Abdera altogether. This would
> mean duplicating a large part of the Axiom functionality, but we'd be able
> to do so in a way that was highly optimized for Abdera's purposes.  This
> would mean a pretty much complete rewrite of the FOM* implementation classes
> but should not lead to any significant API changes. It would give us
> significantly greater control over the parsing process, would allow us to
> make certain dependencies (like Jaxen) optional, and would reduce our
> overall install footprint.  Initially, the new implementation could sit
> along side the Axiom based implementation through it's development, and
> would eventually replace the Axiom implementation as the default.  I know
> there are some folks here that are fans of Axiom (hello Dims! :-)...) and I
> don't want to upset them, but I think there are a number of important
> benefits to replacing Axiom that cannot be overlooked. Thoughts welcome.


> 2. The Abdera i18n code (IRI, unicode, uri templates, etc) should be moved
> to its own subproject under the Abdera Top Level Project. It is extremely
> useful independent of the rest of Abdera and should be developed and
> promoted independently.


> 3. I'm going to be working to integrating the more fully featured RSS
> capabilities contributed by a fellow IBMer. I'm not really all that happy
> with the way it was implemented in the offered patch so I'm going to go back
> through it. Unfortunately I didn't have the opportunity to dig into the
> patch before, but now that I have time to devote to Abdera again, I will go
> through it in more detail.
> 4. Simplification! I wish to continue working to simplify the Abdera
> implementation and APIs and to refine the implementation, configuration,
> etc. In some cases, this may mean API changes, some of which may not be
> backwards compatible but will continue the trend towards a better, easier to
> use, more functional Atom implementation.


> Whatcha think...
> - James


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