Re: Calling web services from Cocoon

[Gianugo Rabellino <gi...@gmail.com>]

First of all, sorry for the delayed reply. I got stuck in urgent
issues and had to leave this aside.

> >Oh, I see. Well, I spent a few brain cycles on it, and I have to admit
> >that I'm not convinced that the Source/SWT way is the way to go. The
> >idea of a Source, to me, is that whatever I write to it can be read
> >back at the same location: this happens with files and with HTTP as
> >well (if you PUT and GET). POST is a different beast and it belongs to
> >RPC rather than to streams.
> >
> I can agree with that the name Source doesn't describe the a POST very
> well, protocol would have been better (at least if you want to post and
> put things to it). An HTTP POST require an input and an output stream
> and that you have completed your writing to the output stream before you
> can read from the input stream, so I don't understand what you mean with
> that it doesn't belong to streams.

It does definitely belong to streams, I used a very bad wording. My
point is actually that a Source, in its current incarnation, is an
abstraction of a stream I/O where write operations are considered as
in "file" operations: whatever I write, can be read back later (which
is not the case with POST). This is, besides, exactly, what the HTTP
RFC considers as the difference between PUT and POST:

"The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a
POST request identifies the resource that will handle the enclosed
entity. That resource might be a data-accepting process, a gateway to
some other protocol, or a separate entity that accepts annotations. In
contrast, the URI in a PUT request identifies the entity enclosed with
the request -- the user agent knows what URI is intended and the
server MUST NOT attempt to apply the request to some other resource.
If the server desires that the request be applied to a different URI"

Moreover, there is no use in considering a Source (as an interface)
where the implementation isn't swappable: I'm using a Source when I'm
in a position not to care where the final result will be written to or
read from. Can be a filesystem, an FTP/DAV server, a database or
whatever. With your "extension" the only source that can be used is
the HTTP one, so I see no need for an abstraction here. It seems, on
the contrary, a perfect candidate for a specific transformer.

> >All in all, I'd rather favor the transformer approach ATM: it seems to
> >me that it fits much better in the overall Cocoon architecture: you
> >build your request inside the pipeline, pass it through a component
> >which performs the POST and grab the result (something you can,
> >besides, do a using a cocoon:// src to the WSProxyGenerator). But I'm
> >open to change my mind.
> >
> I don't see how this differs from my approach.

In practice, the difference is barely noticeable: a different
transformer and different wrapping tags. But conceptually I think
there is an important difference in using a more correct way (Cocoon
wise) of doing things. But, of course, IMHO.

-- 
Gianugo Rabellino