Mailing-List: contact dev-help@abdera.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@abdera.apache.org
Received-SPF: pass (athena.apache.org: local policy)
MIME-Version: 1.0
content-class: 
From: Glen Daniels <glen@thoughtcraft.com>
Subject: RE: Abdera status and future
Date: Tue, 5 May 2009 18:10:17 -0400
Importance: normal
To: <dev@abdera.apache.org>
CC: <abdera-dev@incubator.apache.org>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Message-Id: <20090505221053.C9191488E4A@aalto.aaltohost.com>

Hi all:

Is there a way that Axiom itself could be refactored to better match Abdera=
's needs? Having the SOAP stuff be optional seems like goodness to me, and =
if the XPath stuff is being too much of a load we could consider only enabl=
ing that if Jaxen is on the classpath, etc.

I for one would be happy to look into making Axiom into what you need it to=
 be... It seems a shame to have to roll your own.

Thanks,
--Glen
(sent from my phone)

-----Original Message-----
From: Davanum Srinivas <davanum@gmail.com>
Sent: Tuesday, May 05, 2009 5:55 PM
To: dev@abdera.apache.org
Cc: abdera-dev@incubator.apache.org
Subject: Re: Abdera status and future

James,

If i get some breathing room :) i'll hop in.

thanks,
dims

On 05/05/2009 05:06 PM, James M Snell wrote:
>
>
> Davanum Srinivas wrote:
>> James,
>>
>> +1 to nuke axiom. No problems at all from me. Definitely recommend
>> doing that.
>>
> Wanna help? :-)
>
> - James
>
>> 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 Axio=
m
>>> 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
>>