commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [Morphos] Food for thoughts
Date Fri, 09 Aug 2002 10:28:22 GMT
Sven Kuenzler wrote:
> Nicola Ken Barozzi schrieb:
>> Sven Kuenzler wrote:
>>> Hi,
>>> these are issues I noticed while writing the first simple pipeline 
>>> for Morphos:
>> Happy to read from you again :-)
>>> - What about a ManagedMorpherPipeline with access to a MorpherFactory so
>>>   you could do
>>>   MorpherPipeline.addStage(String morpherName);
>>>   Alternative: MorpherFactory.addStage(MorpherPipeline, morpherName);
>>> Rationale: Remove need for the tedious two-step 
>>> create-Morpher-add-Morpher as seen in Morphos CLI.
>> Ok, it may be nice, but it's not strictly needed.
>> My rule is that Utility methods go in utility classes, or else the 
>> interfaces become too complicated to implement.
>>  Why not make a MorpherPipelineBuilder , with a
>>  MorpherPipelineBuilder.addFactory(MorpherFactory x);
>>  MorpherPipelineBuilder.addPipeline(MorpherPipeline x);
>>  MorpherPipelineBuilder.addStage(morpherName1 x);
>>  MorpherPipelineBuilder.addStage(morpherName2 x);
>>  MorpherPipelineBuilder.addStage(morpherName3 x);
>>  MorpherPipeline MorpherPipelineBuilder.getMorpherPipeline();
> Sounds OK to me. Anyway you're right: This is more or less a 
> convienience thing and we'd bette discuss first things first.

I'm putting it in a todo in status.xml.

>>> - One of the above might be needed anyway: What should happen if a 
>>> Pipeline needs a intermediate output object? E.g. 
>>> FooBar2File,File2Email chain - Who should create this file? How 
>>> should it know that a file is required? etc.
>>>  Alternative: FactoryMorpher interface for Morphers capable of 
>>> creating default output object if none is supplied. Would need 
>>> additional method .getOutput()
>> Hmmm... I don't see the need...
>> Can't we just do
>> MorpherPipeline.addStage(morpherName1);
>> MorpherPipeline.addStage(morpherName2);
>> MorpherPipeline.setInput(input);
>> MorpherPipeline.setOutput(output);
>> MorpherPipeline.morph();
>> and it should work?
>> The point is, we must use pipelines that can handle the correct 
>> Flavors,  so that they can insert automatically a special Morpher for 
>> conversions, or decide how to connect the Morphers.
>> The Pipelines should be right for the Morphers given.
>> I envision StreamConnectingPipelines, SAXConnectingPipelines, and a 
>> AutoConnectingPipeline that senses the dataFlavors and can 
>> automatically assemble itself using these two and SAX2Stream morphers 
>> in between.
> OK, this thing is easy for a SAX only pipline and (I guess) for a 
> StreamConnectingPipeline as well. But what if a Morpher outputs a POI 
> Filesystem for example? If you want to put this between, say, a SAX 
> pipeline and an OutputStream, would this be the job of a  generic 
> AutoconnectingPipeline? 


> If so, how should it know how to create such a 
> Filesystem? Or should there be some POIPipeline which knows what to do?

Yes. There are two levels at least of pipelines.
Pipelines that connect equal systems (SAX2SAX, Stream2Stream, etc) and 
pipelines that assemble them using appropriate Morphers for conversions 
in between.

>> This clearly means that we need a getInputDataFlavor and 
>> getOutputDataFlavor methods in the Morpher, so that the pipeline can 
>> do this and also check that the Morphers can be pipelined.
> In that case, could you please elaborate more on the OutpuFlavor 
> concept? I read the sample in the Morpher interface docs (which is still 
> talking of DataType, BTW ;)) and have not grasped yet where this is 
> heading.

I define that objects have two characteristics: what they contain, and 
how they contain it.
You can have Morphers that convert only one, or only the other, or both.
ObjectFlavor describes what an Object contains and how it contains it.

Ok, let me try to explain it better with examples.

The following have same "what" and different "how".
Their Flavor changes only in the how.

XML stream|  what:xml  how:stream
XMLDOM    |  what:xml  how:DOM

The following have different "what" and same "how".
Their Flavor changes only in the what.

SVG stream|  what:xml  how:stream
gif stream|  what:gif  how:stream

The following have different "what" and different  "how".
Their Flavor changes completely.

SVG DOM   |  what:xml  how:DOM
gif stream|  what:gif  how:stream

If a pipeline is asked to convert SVG file to GIF file, it can look in a 
descriptor that tells him:

  Stream2SAXMorpher   |  what:xml           how:stream->SAX
  SVG2GIFMorpher      |  what:xml->image    how:SAX->object
  Image2StreamMorpher |  what:image->gif    how:object->stream

As you see pipelining them I get

what: xml->image->gif    how:stream->SAX->object->stream

>>> - How to handle Parameters (like stylesheet files, cf. XSLTMorpher) 
>>> Convience Interfaces should be fine, as long as their signatures obey 
>>> the bean protocol?
>> We thought initially that there was no need for interfaces, just the 
>> Javabeans gets/sets.
>> We can use Beanutils in automatic configuration systems.
> But a convinience interfaces won't hurt? For applications that don't 
> need a config system because they "know what they are doing" with their 
> morphers.

If they know what they are doing, they just use the bean methods.
An interface is needed only for generic use, and that is done via the 
beanutils package, that has such an interface.

>>> - Work out Morphers lifecycle. Esp. that of passive Morphers. When to 
>>> allocate resources etc. Morphers might need to reset() between two 
>>> morph()s
>> IMHO there should be no new need.
>> -initial state-
>> setInput
>> setOutput
>> setXXX
>> setYYY
>> -set state-
>> morph
>> -initial state-
>> ...
>> After a morph it's ready to roll again, because the SAX-based morphers 
>> should be initiated by the morph() method of the first one in the SAX 
>> chain.
> So a SAXMorpher would initialize itself in its startDocument() method?

Or at the end of an endDocument.

>>> - What about "Prepared Morphers"? E.g. XSLTMorpher using Templates 
>>> object.
>> I originally made getPreparedMorpher() signatures in the Factory.
>> Is this ok for you?
> The question actually should have been why this signature disappeared :-)

Hehehe. Since I want to keep things clean, I wanted to see if anyone 
complained ;-)

> Personally I don't know whether to differentiate between prepared and 
> unprepared Morphers.

Then let's keep this for when we need it.

>>> - Merging two Morphers? E.g. 
>>> XMLOutputtingMorpher+XSLStylesheetOutputtingMorpher both connect to a 
>>> XSLTMorpher doing the transformation
>> Could you please elaborate more?
> Yes. But I think we postpone this ATM.

Ah, shucks ;-/ It seemed so interesting ;-D

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message