cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: WSProxyGenerator
Date Mon, 10 Feb 2003 20:13:25 GMT

Pier Fumagalli wrote, On 10/02/2003 20.13:
> On 10/2/03 18:30, "Vadim Gritsenko" <vadim.gritsenko@verizon.net> wrote:
> 
> 
>>IMHO, web service != WSDL.
>>IMHO, web service = transport + xml, thus HTTP+XML is a web service.
>>AFAIU, WSDL is the way to describe (formalize) web service. But it
>>perfectly works without it.
> 
> 
> I use the "Goddard Compliancy Test for Buzzword"...
> 
> - If I say "web service", Goddard will again reply "too complicated, we
>   don't want to use that J2EE thing"
> 
> - If I say "XML over HTTP via a proxy", Goddard will reply: "Ah, ok, why
>   didn't you say so in the first place, you muppet?"

I use the "Andy Compliancy Test for Buzzword"...

  - If I say "Inversion o Control", Andy will again reply
    "too complicated, we don't want to use that Avalon thing"

  - If I say "container sets up the object ", Andy will reply:
    "Ah, ok, why didn't you say so in the first place, you winblows?"

;-P

> Forgot to mention, Mr Goddard is my boss! :-)

Tup, Andy is the nearest thing I have to a boss... hehehe ;-P

>>OTOH, may be ProxyGenerator should go into the core... Dunno.
> 
> 
> It might make sense because it's basically a file generator but it gets
> "files" off somewhere else (It's like the file generator + steroids), but it
> relies on two external things: commons-httpclient and commons-logkit (hey'
> it's not me! :-) It's httpclient).

Then it makes perfectly sense to put it out of the core.
The core should have the least possible dependencies: JDK, Avalon, 
Xml-stuff.

That's also why I want to separate the environments too as done with blocks.

> Shall I put it now alongside the WebServiceProxyGenerator, then I refactor
> all samples, and then once that step is done and we're all happy with it, we
> decide to either keep it in there or separate it out as a block, and "get
> rid" of the old version???

Rule of the thumb: in a block we have classes that have:
  - roughly same jar dependencies
  - they are used in exclusion for the same task
  - they are used together for a single goal

We also have generic blocks and specific blocks.
"database" is generic.
"batik" is specific.

Eventually we will have a generic database block and specific sublocks, 
but that's inheritance, and a later thing to do.

> (I'm new to the game,

suuuuuureeeee ;-P

>  so, it's your call folks)


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message