Abdera status and future

[James M Snell <ja...@gmail.com>]

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

Re: Abdera status and future

[Jun Yang <jy...@gmail.com>]

On Tue, May 5, 2009 at 1:32 PM, James M Snell <ja...@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.
>

+1


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

+1


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

+1


> Whatcha think...
>
> - James
>

Jun

Re: Abdera status and future

[Davanum Srinivas <da...@gmail.com>]

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

Re: Abdera status and future

[James M Snell <ja...@gmail.com>]

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
>

Re: Abdera status and future

[Davanum Srinivas <da...@gmail.com>]

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

Re: Abdera status and future

[Luciano Resende <lu...@gmail.com>]

On Tue, May 5, 2009 at 1:32 PM, James M Snell <ja...@gmail.com> wrote:
> 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.
>.....
>
> Whatcha think...
>
> - James
>

In the past, the only issues with the tentative 1.0 release was some
legal changes that needed to be done.... what's the time frame you
have to try to push the release out ? maybe i could help on the legal
files review and additions required.


-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: Abdera status and future

[Ugo Cei <u....@sourcesense.com>]

On May 5, 2009, at 10:32 PM, James M Snell wrote:

> Moving foward, there are a number of changes and refactorings I'd  
> like to look at:


+1 to all.

I don't have anything against Axiom, but I'd welcome everything that  
makes building Abdera and bundling it with other programs simpler.  
I've had my share of library conflicts and class-loading issues wen  
doing the latter.

	Ugo

-- 
Ugo Cei
Sourcesense - making sense of Open Source: http://www.sourcesense.com