commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [Morphos] Proposal for new interface
Date Fri, 06 Sep 2002 07:46:07 GMT

Andrew C. Oliver wrote:
> Nicola Ken Barozzi wrote:

>> Andrew C. Oliver wrote:
>> > I think your scope is too broad for the moment. Locator? Just take the
>> > input you're given and leave the location to the caller.
>> Ahem, the point is that we need to indicate that the Morphers need to 
>> start with an object, not a reference.
>> We had put a Morpher that morphed an URL into a SAX stream... which is 
>> plain wrong, since a URL is a locator to a stream.
>> So we just put that interface there, to be clear.
>> Our plan is to have a couple of Locators, no more (URL, File).
> Why.  I'm just questioning whether this belongs in morphos or if you 
> can't just take a Stream.  You can get URLs into Streams, files into 
> streams, etc.  Why have a needless abstraction. 
> Stick with stream and reduce complexity.

I'd say, let's ditch Locator and have simply URLS up front for
And remember that Morphers must Morph stuff, not identify and locate stuff.

URL = UR*Locator*   ;-)

>> > Secondly, what do you mean SAX morpher's?  You have marc's stuff.  If
>> > you want to make them statelss you're kidding yourself
>> > for many applications.  But you can use a builder pattern and have hte
>> > "morphers" build a model... but ultimately you must store state
>> > for many formats, etc.  Unless you're going XML->XML.
>> Stateless between calls.
>> They have of course to have an internal model (state), but only 
>> atomicly, per invocation.
>> ie
>> *initial state
>> **morph(in, out) [inside here anything can be done, because java 
>> method invocations are scoped
>> *initial state
>> If instead I do
>> *initial state
>> **setInput(in)
>> **''statefull state - input set''
>> **setOutput(out)
>> **''statefull state - output set''
>> **morph()
>> *initial state
>> it's not stateless.
>> It's cool because I can make a pipeline that is really preemptive; I 
>> can call the first morpher, stop and do other things, come back and go 
>> on... really scalable.
>> With SAX it's not possible, because we must assemble pipelines and 
>> then start the run.
>> The stopping of the generation must be done by the parser.
>> I see the first case as "horizontally" preemptive, the second as 
>> "vertically" preemptive.
>>   1)
>>       (a1,2,3) ----> (b1,2,3) ----> (c1,2,3)
>>   2)
>>       (a1) ----> (b1) ----> (c1)
>>       (a2) ----> (b3) ----> (c3)
>>       (a4) ----> (b4) ----> (c4)
>> How do we define this?
>> How do we combine these?
> I'm not sure its a good idea to do in the first place.  Or rather you're 
> trading one complexity for another.   Look at some of the existing 
> elementprocessor stuff.  There are times when to fit to the model a call 
> to the parent and sometimes grandparent is necessary. 

Ok, but this has nothing to do with the first part of the "stateless" 
thing, ie atomic morph method.
So we are looking at the other thing, ok.

> I'm not sure this 
> can be solved in a completely stateless manner. 
> You can borrow an AWT event model idea and combine it with the builder 
> pattern and build a model but you must be imminently predictive. Meaning 
> you'd need to stuff the upstream data into the "buildee" in advance.  
> Meaning you must "know". 

Ah, ok, I get it.
You mean that in the "vertical" example, you must retain the internal 
state between SAX events. Hmmm, you are right.

Which means that only in the first case I can be stateless (inside each 
Morpher) between calls.

> Thats kinda icky.  So ensure the tradeoff here between object 
> instantiations is worth the tradeoff. 

Ok, you are right.
SAX basically "verticalizes" the processing and combines stages in a 
single stage with many phases that all need to keep their internal state 
between invocations :-/

So ok, it really seems that SAX pipelines must have stateful Morphers, 
because they do not perform it all in a method but have multiple method 

So I guess that SAX pipelines will always have to be treated atomically.

> (example kinda sorta:

> -
> Imagine SAX as the source instead of a binary file and you see what I 
> mean.  But its a tradeoff as you can see.  I MUST know in advance.  This 
> example is a flattened version but easy to read.)

Yes, you are right.

Ok, so here is the new possibility:

    *'''Object''': the information
    *'''Morpher''': it acts on the information
    *'''MorpherPipeline''': the manager of the flow of the morph of the 
Object to an Object via Morphers.

    interface Morpher
        morph(Object input,
              Object output,
              Notifier notifier
              Context context)

The notifier is an "ErrorHandler".
We can use ErrorHandler from other packages if you prefer.

Context is about runtime configuration info.
We can use Properties or Map instead.

    interface Morpher
        morph(Object input,
              Object output,
              ErrorHandler eh
              Map parameters)

        setConfigutarion(Map conf){


   abstract class SimpleMorpher
        morph(Object input,
              Object output){

                 new nullErrorHandler,
                 new HashMap();

        setConfigutarion(Map conf){


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