abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "joe kim" <joe....@gmail.com>
Subject Re: Atom Data Model and Testing
Date Fri, 30 Jun 2006 23:35:29 GMT
> -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?

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

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

> We can already do this.
> class MyFeed extends FOMFeed {
>   ...
> }

FOMFeed is not general purpose enough due to it's dependence on axiom.

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

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


View raw message