cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mao <james....@iona.com>
Subject Re: isGET in interceptors...
Date Fri, 01 Dec 2006 03:21:48 GMT
Hi Dan,

>
> Not to me. Now we have 9 different references to isGET scattered 
> throughout
> the codebase. What happens when users write their own interceptors? 
> They're
> going to be surprised to find that their interceptor breaks GET usage. 
> We've
> just made things harder from a developer and user's perspective.
User will not care about this, they got the feature, they gonna enjoy it.
For a developer, they also like an easy way to do things, isGET is 
easier to understand than introduce another interceptor, and change the 
chain dynamically,
that's harder to understand and and harder to debug, and harder to maintain
>
>
> And I think to remove the interceptors dynamically also cause the
>> performance issue.
>
>
> I don't think it will be that much of a performance hit. Also, I don't
> really care about the performance of the SOAP HTTP GET case. Its a 
> secondary
> concern of ours.
I didn't say a *LOT*, what i said is *better*
*Performance* definitely is a *feature* in my mind, don't need to put it 
in the first place, but if we have a good performance, there's no reason 
to change it back to a bad performance.
>
> The isGet just boost the processing, it will return fast if it detect
>> it's a GET method and the interceptor has nothing to do with GET.
>> I didn't see any harm to do so, it's just a three check lines, the code
>> is readable, and easy to maintain.
>> And it's extremely fast  when you try SOAP GET, or XML GET, i have
>> checked in a demo to show how it works with SOAP12
>> it's in samples/soap12, but you can try other demos as well.
>> Usage:
>> > ant client.get
>>
>> You can even  use your favorite browser to GET the service
>>
>> I might think to check in a PHP demo or Ruby demo to show how other
>> language can consume CXF  service through the HTTP GET.
>
>
>
> I'm aware of how it works. And I like the feature. But I don't like 
> the way
> it was implemented as it has side effects all throughout the code 
> base. This
> is part of the reason the HTTP binding just synthesizes a document.
I guess developers and users are all like feature, because it's easy and 
fast.

>
> I think we need to come up with a better way. My preference would be to
> unify the code in the HTTP binding and the current HTTP GET/POST for 
> the XML
> & SOAP bindings.
The HTTP GET we implemented and the HTTP binding are different things, i 
don't think we need to combine.
If it's GET, there is no need to synthesizes a document, that will slow 
down the processing.

And I think that's two different use scenario, the HTTP binding require 
user to add extra annotation(extra learning curve, and need to know how 
the mapping works, then you will add documentation, explanations do have 
cost), in isGET way, they don't
What user need to now is that he/she can use URLConnection invoke the 
service directly, that's *all* he/she need to know, simple, easy, and fast
For a developer, there's nothing more he/she need to do, almost done for 
them, what he/she need to know is understand what isGET mean, that thing 
can understand in seconds, right?

So, all in all, the only thing in common is that they all used the GET, 
but that's not the reason we need to combine, they are really two 
different use scenario.
If someone can not understand what isGET means, i'll be surprised.  Let 
me know if there's any problem of isGET that block your work or 
understanding.

BTW, i have updated the READEM

Thanks,
James.

Mime
View raw message