commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <a...@superlinksoftware.com>
Subject Re: [Morphos] Proposal for new interface
Date Thu, 05 Sep 2002 23:38:43 GMT
Nicola Ken Barozzi wrote:

> http://metamorphosis.krysalis.org/cgi-bin/mmorphosiswiki.pl?MorpherSpecification 
>
>
> 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.

>
> > 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.  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".  

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

-Andy

(example kinda sorta:
http://jakarta.apache.org/poi/javadocs/javasrc/org/apache/poi/hssf/dev/EFHSSF_java.html#EFHSSF

-
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.)

>
>> Nicola Ken Barozzi wrote:
>>
>>> http://metamorphosis.krysalis.org/cgi-bin/mmorphosiswiki.pl?MorpherSpecification

>>>
>>>
>>> '' Better proposals? ''
>>>
>>> We have these actors:
>>>
>>>   *'''Locator''': it brings information
>>>   *'''Morpher''': it acts on the information
>>>   *'''''Output (TBD)''''': endpoint
>>>   *'''MorpherPipeline''': the manager of the flow of the transaction 
>>> from a Locator to an Output via Morphers.
>>>
>>>
>>>   interface Locator
>>>   {
>>>        Object locate();
>>>   }
>>>
>>>   interface Morpher
>>>   {
>>>        Object morph(Object object );
>>>        //OR  morph(Object input, Object output)
>>>   }
>>>
>>>   interface Output
>>>   {
>>>        Notification process( Object object, Object output );
>>>   }
>>>
>>>   Example:
>>>
>>>   interface FixedIdInput
>>>   {
>>>      Object locate(Object o){
>>>         return "FIXEDID125"
>>>      }
>>>   }
>>>
>>>   interface DuplicateStringMorpher
>>>   {
>>>      Object morph(Object obj){
>>>         String objString = (String) obj;
>>>         return objString + objString ;
>>>      }
>>>   }
>>>
>>>   interface SystemOutOutput
>>>   {
>>>      Notification process( Object object ){
>>>         System.out.println(obj);
>>>         return new Notification(Notification.SUCCESS);
>>>      }
>>>   }
>>>
>>> Ok, this is very trivial, but it shows that:
>>>
>>> # If we pass round Objects we have more flexibility but possible 
>>> casting errors. I resolved this by resorting to a Factory that gives 
>>> you the right "Morpher" for the right task.
>>> # How can we make SAX morphers?
>>> # How can we configure (parametrize) the morph() run?
>>> # How can we have a pipeline with both SAX and Stream and JavaBean 
>>> manipulators?
>>> # The above Morpher can only operate on a single input. What if I 
>>> already have the output Object and want to
>>> populate it with what comes from the input, like in Stream 
>>> manipulators?
>>> ie I have an InputStream and an OutputStream... how can I do it with 
>>> this Morpher? I guess that the Output is the answer...
>>>
>>>
>>> '''''NOTE:''''' ''Also See InfoMover threads 
>>> [http://marc.theaimsgroup.com/?t=102950602400006&r=1&w=2 here] and 
>>> [http://marc.theaimsgroup.com/?t=102952200100001&r=1&w=2 here] in 
>>> the mailing history of avalon-dev''
>>>
>>>
>>
>>
>>
>>
>>
>




--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message