abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jasn...@gmail.com
Subject Re: Abdera status and future
Date Tue, 05 May 2009 22:20:20 GMT
Well, I was thinking of starting with axiom as it is and slashing/refactoring down from there.
 If the result can help make axiom better then bonus. 

- James 
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Glen Daniels <glen@thoughtcraft.com>

Date: Tue, 5 May 2009 18:10:17 
To: <dev@abdera.apache.org>
Cc: <abdera-dev@incubator.apache.org>
Subject: RE: Abdera status and future


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 enabling 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 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
>>

Mime
View raw message