Jeremy Quinn wrote:

>At 12:22 am +0100 23/2/02, Sylvain Wallez wrote:
>
>>Hi team,
>>
>>Considering the discussions about the FileWritingTransformer, Cocoon
>>symetry and Stefano's source/drain RT, I added in
>>org.apache.cocoon.environment a new interface I already talked about :
>>WriteableSource. It adds writing methods to Source's reading abilities.
>>
>Fantastic!
>
>>Writing can occur in two ways :
>>- to write SAX events, call getContentHandler() to have a consumer for
>>these events,
>>- to write bytes, call getOutputStream() to write them.
>>
>>It comes with a first implementation : FileSource, which handles (guess
>>what) files. An additionnal entry in <source-handler> makes this
>>implementation prevail over the default URLSource. Writing occurs with a
>>simple lock mechanism that prevents simultaneous writes.
>>
>Nice to see how you have done it, much cleaner than mine ;)
>
>>The door is now open to other implementations that will allow us to
>>write anything anywhere just as Source already allows to read anything
>>anywhere. Some possible implementations include xmldb (Gianugo ?), SQL
>>blobs, http/ftp upload, etc.
>>
>This is going to be very cool!
>
>>As the first implementation supports atomic updates, and some other are
>>likely do support it also, I was thinking of adding a rollback() method
>>on WriteableSource. But rollback is more related to the OutputStream or
>>ContentHandler than to the source itself. So what do you think ?
>>
>I think we still have the problem whereby Exceptions thrown by other parts
>of the pipeline can end up trashing the contents of the WritableSource,
>because the SourceWriter does not know this has happened.
>
>Is there any way rollback could be used under these circumstances?
>
After more thoughts, I will add the following methods to handle 
abort/rollback on a WriteableSource :

  boolean canAbort(ContentHandler ch)
  boolean canAbort(OutputStream os)
  void abort(ContentHandler ch)
  void abort(OutputStream os)

This allows for transactional sources, such as the temp-file based 
FileSource of an hypothetical SQLSource. The abort method doesn't apply 
on the source only, but on the result of getContentHandler() or 
getOutputStream().

>>                              --o--
>>
>>Jeremy, I also quickly updated the FileWritingTransformer so that it
>>uses any WriteableSource instead of just files.
>>
>
>Even better ;)
>
>I think it needs a change of name right? Or is it even obsolete now?
>
>WritableSourceTransformer anyone?
>       <source:write xmlns:source="http://apache.org/cocoon/source/1.0"/>
>
>Or TeeSourceTransformer, TeeJointTransformer, DownTheDrainTransformer ;)
>
>Or should something like the XInclude Transformer(s) and
>WritableSourceTransformer be united into a single SourceIOTransformer that
>has tags for both read and write?
>
>       <source:write src="file:/blah.xml"/>
>       <source:read src="dbxml:/collection/document"/>
>
>>Could you please look at it ?
>>
>Looks like a good job to me ....
>
>>Another update would be also to the 'serializer' parameter fully
>>optional so that SAX events are sent directly to the result of
>>WriteableSource.getContentHandler(). This would for avoid parsing the
>>output of the serializer for native XML sources such as xmldb.
>>
>OK, I'll do this.
>Just to make sure I understand what you are suggesting properly ....
>
>If the Serializer param is supplied, I get the Serializer and give it the
>OutputStream from WriteableSource.getOutputSource() and send events to the
>Serializer's ContentHandler.
>
>If no Serializer parameter exists, I instead send events directly to the
>ContentHandler I get from WriteableSource.getContentHandler().
>
That's exactly what I meant : if no serializer has been specified, just 
use the ContentHandler provided by the WriteableSource and let the 
source do it's job directly with SAX events. If you look at FileSource, 
it used an XML serializer internally, but an xmldb source that natively 
stores XML won't need it.

<snip/>

Sylvain

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to