cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Postable block protocol
Date Thu, 26 Oct 2006 20:53:25 GMT
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

Mime
View raw message