Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of jasnell@gmail.com designates
 64.233.184.234 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=uD4O2CHw0qPfCQrjARoY1JGy4FjF8MCQ8o2VyCnzaR/G3EzRA57MK6v+Z5QcKAEJaF8rFSrV17ch4PImUXNu3ZRqGQG1c2U5zWQXE/4GW23s2cbBXmf3G5JG2bZ5rFLY5zPqr4SkXv9UfLGuFDQkQ1ozH0xymbqZCGeSg21YDg4=
Message-ID: <44A5D222.1080900@gmail.com>
Date: Fri, 30 Jun 2006 18:38:42 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: abdera-dev@incubator.apache.org
Subject: Re: Atom Data Model and Testing
References: <35379c520606301441k518b8e61ua9f211559250e620@mail.gmail.com>
	 <44A5A7ED.30706@gmail.com>
 <35379c520606301635u7af5f85ej5e8ef84c4e09111@mail.gmail.com>
In-Reply-To: <35379c520606301635u7af5f85ej5e8ef84c4e09111@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


joe kim wrote:
>> -1. The current interface+impl mechanism provides a great deal of
>> flexibility in the implementation and gives us built-in serialization to
>> and from XML using Axiom that is very high performance and efficient.
> 
> What performance data are you basing this on?
> 

Rob Yates (who is on paternity leave right now so likely can't respond
right now) has performed some performance analysis of Abdera with Axiom
relative to Rome (which separates the model impl from the parsing).
Parsing just titles and links from Tim Bray's feed, Rome used 6+MB of
RAM and over 600 million CPU instructions; Abdera with Axiom used around
700k of RAM and around 90 million CPU instructions.  The secret of the
performance improvement was in the use of Axiom and StAX -- that is, to
say, pull parsing and lazy creation of the object model.

I had originally started down the path you are suggesting, this is
better.  Please, run some performance analysis of your own.  Look at the
stack traces.  Compare them with those of Rome.  I think you'll be
surprised at how much kruft is *not* there *because* of the direct
dependencies on Axiom and StAX.

If, after running some performance tests, you think the pojo approach
would still be easier/simpler, I would encourage you to implement it
side by side with the Axiom stuff (create a new set of impl classes for
the interfaces, including the parser, factory, xpath, etc) and do a
side-by-side comparison of the two.

>> Factory factory = new MyFactory();
>>
>> Or, you could also...
>>
>> Factory factory = new FOMFactory();
> 
> I suggest that writing MyFactory will be easier if the base data model
> is implemented as pojo's.
> 

Go ahead and give it a try.  I think you'll find more benefit to Axiom
that you're giving it credit for.

>> The current configuration model is in place to allow for alternative
>> default implementations of the object model.  For example, we currently
>> have at least one project going on internally that is working on
>> replacing the Axiom-based implementation with an SDO based
>> implementation, using the exact same set of interfaces.
> 
> That sounds good.  So they are using the interfaces from
> org.apache.abdera.model and are implementing their own Factory?
> 

Yes.

>> We can already do this.
>>
>> class MyFeed extends FOMFeed {
>>   ...
>> }
> 
> FOMFeed is not general purpose enough due to it's dependence on axiom.
> 

The dependency on Axiom gives us our performance advantage as well as
xml serialization for free.

>> I don't see this as buying us anything relative to what we already have
>> and would likely degrade the performance advantages of the Axiom-based
>> impl we already have in place.
> 
> It buys a cleaner way to implement data model flexibility.  Inheriting
> from a class is really nice because you do not have to reinvent the
> wheel, but things start getting nasty when you have to inherit kruft
> that you don't need, such as axiom code when using a different parser.
> How much do you really think this will degrade performance?  My
> feeling is that it would be negligible.  Sorry, but I have to quote
> Knuth, "Premature optimization is the root of all evil (or at least
> most of it) in programming."
> 

What's nice about Axiom is that you can actually replace the underlying
parser.  In Abdera, Axiom is not kruft, it provides the fundamental XML
infoset model and XML support.

However, like I said, the reason Feed, Entry, etc are interfaces is to
allow for alternative implementations.  Someone could come along and
plug-in a non-Axiom based implementation of those interfaces and have it
just work.

>> -0.5. JUnit has much broader support and, so far, has done everything
>> we've needed it to do.  Unless there is something that TestNG offers
>> that we absolutely need and cannot get with JUnit, I don't see the
>> advantage.
> 
> Both JUnit 4 and TestNG provide the same capabilities as the current
> JUnit 3.8 plus some.  I am not sure what the benefits of "broader
> support" are.  JUnit 4 and TestNG can be called from ant and eclipse
> and probably maven.  Anyhow, we can take this to a new thread.
> 
> Joe
> 

- James