ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: Performance Comparison
Date Tue, 04 May 2010 10:50:12 GMT
On Tue, May 4, 2010 at 03:31, Daniel Kulp <dkulp@apache.org> wrote:
> On Monday 03 May 2010 3:20:36 am Dennis Sosnoski wrote:
>> Whoops, meant to have this in my first response...
>>
>> Andreas Veithen wrote:
>> > Each of the two approaches (porting WSS4J to Axiom / building a new
>> > optimized Axiom+DOM implementation) have their pros and cons and I
>> > think there is enough room for the two. They could even be
>> > complementary provided that the new Axiom+DOM implementation has a
>> > lower memory footprint and better performance.
>>
>> I can't really see much of a pro in porting WSS4J to Axiom. This would
>> mean either forking the code, with the associated maintenance issues, or
>> deliberately choosing to lower WSS4J's performance with other
>> applications just so that Axis2 improves (and creating an Axiom
>> dependency for everyone else using WSS4J).
>
> Just to extend this a bit further (or make it more generic), change this to:
>
> I can't really see much of a pro in porting <insert favorite XML processing
> library here> to Axiom. This would mean either forking the code, with the
> associated maintenance issues, or deliberately choosing to lower <insert
> favorite XML processing library here>'s performance with other applications
> just so that Axis2 improves (and creating an Axiom dependency for everyone
> else using <insert favorite XML processing library here>).

If you add "unless the port would leverage capabilities of Axiom that
are not available in DOM" to the first sentence, then I fully agree.
If the only purpose of the port is to get around limitations in Axiom
then it would definitely make more sense to invest the time into the
improvement of Axiom. Even if there is a need to use Axiom specific
features, there is a possibility to use those features while still
keeping the DOM API, simply by having something like an abstract
DOMUtil class with two implementations (one for standard DOM and one
that contains implementations optimized for Axiom). I don't know much
about the project of Saliya et al., so I don't know if it makes sense
to do a fork in that particular case.

> Seriously, I really don't think the problem is limited to WSS4J.  It really
> would apply to any library that does some sort of DOM based XML processing.
> Things like XSLT engines, XPath things, etc...   Should ALL of them be forked
> to have Axiom versions?   I personally think that's nuts.   Let the security
> folks do security things.  Let the XSLT folks do XSLT things. Etc...   Let the
> Axiom folks concentrate on Axiom things.

+1. That is exactly the reason why I started to play around with some
new stuff that may become later the starting point of Axiom 2.0.

> Standard API's are good for a reason.   I would be good if the standard API's
> can be made to be fast.   That's my opinion.
>
> Dan
>
>
>
>>
>> Implementing a DOM interface usable by WSS4J on top of a modified Axiom
>> seems like a better choice, so that Axis2 can avoid unnecessary
>> conversions and boost its performance without hurting other users of
>> WSS4J. Or instead using a simpler version of build-on-demand than that
>> implemented by Axiom, as discussed in the earlier reply.
>>
>>   - Dennis
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message