Vadim Gritsenko skrev:
Daniel Fagerstrom wrote:
What I would propose is to create some new pipeline components that
calls postable sources, and make the block protocol postable. Then we
have four cases for the different combinations of XML or non XML input
and output respectably:
non XML -> non XML
<map:read type="service" src="block:b:/foo1"/>
non XML -> XML
<map:generate type="service" src="input.txt">
<map:parameter name="service" value="block:b:/foo2"/>
</map:generate>
XML -> XML
<map:transform type="service" src="block:b:/foo3"/>
XML -> non XML
<map:serialize type="service" src="block:b:/foo4"/>
It took me at least 5 min to understand what you mean... So I want to
confirm that I got it right. :)
Looking at my text I see that I didn't provide much clues about what I
meant ;)
Do you mean that proposed "service" Reader / Generator / Transformer
will resolve the Source object passed to it and will try to "forward"
post body (if any) of the current Request into that Source?
No, they don't forward the post body of the request. The transformer
forward its input stream to the postable source provided as src
attribute and then use the output of the source as output of the
transformer.
+---------+
| |
XML >---+-+ T +-+---> XML
| | | |
+-+-----+-+
| |
V A
+---------------+
|Postable source|
+---------------+
The serializer do about the same but with octet stream output.
The generator read an octet stream from the source in its src attribute
and feed it to the postable (non XML -> XML) source refered to in the
service parameter. And the reader does the same but for non XML -> non
XML. The reader should have had a service parameter as the generator to
make sense.
<map:read type="service" src="input.txt">
<map:parameter name="service" value="block:b:/foo1"/>
</map:read>
And it would be better to use a service parameter instead of the src
attribute for the postable source for the transformer and serializer as
well for having a consistent notation.
Do I get it right that you are proposing to introduce new PostableSource
interface?
And WRT to ModifiableSource, I do not think it is a good match here.
Semantically, good old Source.getInputStream() corresponds to GET,
ModifiableSource.getOutputStream() corresponds to PUT, so it looks like
'postable' source should not be using ModifiableSource but introduce its
own interface.
I agree with that. The ModifiableSource extends Source so it has both an
input and an output stream method, so the interface would be enough for
handling posts. But as the semantics of a post is different from a put
it would be a good idea to mark it with a new PostableSource interface,
so that the different service sitemap components doesn't try to post to
an ModifiableSorurce that just expect PUTs.
/Daniel
