Mailing-List: contact dev-help@abdera.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@abdera.apache.org
Received-SPF: pass (nike.apache.org: domain of jasnell@gmail.com designates
 74.125.44.152 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject
         :content-type:content-transfer-encoding;
        b=p3Hhs9tNNw4/Q9RNVkuJ3y0AudMJpd/EH6BCoX2J+KXTE7lk4ktnMmdS1zvoKazW7G
         tgZeifPJRUrLZj/K03qrGqyKwG/nl8dspzA/pmAI4a9gyW+aWReN4VIanFT65AGTAY8J
         dAegpyKwDnY5xxKLIxa+J1IVQQJYKQuaOiO8Q=
Message-ID: <4A00A27B.5030803@gmail.com>
Date: Tue, 05 May 2009 13:32:59 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090409)
MIME-Version: 1.0
To: abdera-dev@incubator.apache.org
Subject: Abdera status and future
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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