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 davanum@gmail.com designates
 74.125.46.155 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:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=hILe87VCVaoLVoNbp44bcKhAkxlU3EsCcKLJxcz2aNViNWH8ADevQXEctblLjKBgHs
         TfZY+8yX/JrCTwCn5QoheYJahWYYcASoosUQXQ27xkj8xg9IGVeQv6faf35Km1xoBBJC
         J3GvIGw2CDda62R6A4AI8YVR1vDUGQ5YhOxms=
Message-ID: <4A00A9B3.5040402@gmail.com>
Date: Tue, 05 May 2009 17:03:47 -0400
From: Davanum Srinivas <davanum@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2
MIME-Version: 1.0
To: dev@abdera.apache.org
CC: abdera-dev@incubator.apache.org
Subject: Re: Abdera status and future
References: <4A00A27B.5030803@gmail.com>
In-Reply-To: <4A00A27B.5030803@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

James,

+1 to nuke axiom. No problems at all from me. Definitely recommend doing that.

thanks,
dims

On 05/05/2009 04:32 PM, James M Snell 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