You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/09/05 13:58:42 UTC
[Morphos] Proposal for new interface
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''
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Morphos] Proposal for new interface
Posted by "Andrew C. Oliver" <an...@superlinksoftware.com>.
Nicola Ken Barozzi wrote:
>
> Andrew C. Oliver wrote:
>
>>>
>>> We cannot have the SAX pipeline do something, give me an
>>> intermediate result, then restarted by giving the intermediate
>>> result back, etc.
>>>
>>> You can do it with Stream Pipelines, because you call the first
>>> Morpher on a Stream, serialize the output to a File, then give that
>>> file to another Morpher... etc.
>>
>>
>> Oh god that sounds slow and you can't do that with HSSF. Don't think
>> in terms of files.
>
>
> If you have a server that is overloaded, you cannot have a thread per
> request, you need to stop processing of some requests for some time
> and continue later; in this case I can store the result somewhere (in
> RAM, if not file), and do it later, preemptively.
This is what the OS and operating system is supposed to do. On
Windows/UNIX/Linux you have pre-emptive multiasking and swap memory.
This should work nicely with the JVM. There are repoorted glitches in
the JVM that can make this problematic but this isn't the place to solve
that.
>
>>>
>>> Yes, we need this.
>>>
>>> I propose:
>>>
>>> boolean canMorph(ObjectFlavor input, ObjectFlavor output) {
>>> ...
>>> }
>>>
>>> It's better be because if input is a Stream, it's too generic to
>>> understand if it can work on it.
>>>
>>> ObjectFlavor[] getSupportedInputFlavors()
>>> ObjectFlavor[] getSupportedOutputFlavors()()
>>>
>>> A morpher could support multiple ObjectFlavors.
>>>
>> Why ObjectFlavor?
>
>
> "
> >> It's better be because if input is a Stream, it's too generic to
> >> understand if it can work on it.
> "
>
> If I ask the POI morpher, "can you transform a contenthandler into a
> stream"?
>
> Reply : yes.
>
> Then I give it a gif image in the streams and it breaks horribly.
Ahh okay. I wasn't testing for that here. I was providing dynamic
specification for what the two objects you put could
be. Compile time would be better in this case, but thats fine. So lets
go a bit deeper. Rather than objectflavor we should have two additional
methods to check for morphsContentType()... and pass in the mime type.
Because the only way you'll know there is a gif in that stream in many
circumstances is if you have the mimetype.
In addition to morphers we might want to have "ContentTypeIdentifiers"
which can use Majick byte matching to identify content, but that should
be outside the scope of this discussion.
>
>> I don't see a need for this, there is already support for doing this
>> in the JDK and code examples (anything using the compareable
>> intereface).
>
>
> Compareable?
> Me no understand...
>
> In JDK there is java.awt.datatransfer.DataFlavor, but you know what it
> means to have an awt import...
> ...also something similar is there for ptinting, but they are simply
> overspeced and bloated.
>
> What examples are you talking about?
>
See this:
344 public boolean equals <http://jakarta.apache.org/poi/javadocs/javasrc/org/apache/poi/hssf/record/NumberRecord_java_ref.html#NumberRecord.equals%28Object%29>(Object obj)
345 {
346 if (!(obj <http://jakarta.apache.org/poi/javadocs/javasrc/org/apache/poi/hssf/record/NumberRecord_java.html#NumberRecord.equals.obj> instanceof CellValueRecordInterface))
347 {
348 return false;
349 }
350 CellValueRecordInterface <http://jakarta.apache.org/poi/javadocs/javasrc/org/apache/poi/hssf/record/CellValueRecordInterface_java.html#CellValueRecordInterface> loc = ( CellValueRecordInterface ) obj <http://jakarta.apache.org/poi/javadocs/javasrc/org/apache/poi/hssf/record/NumberRecord_java.html#NumberRecord.equals.obj>;
351
352 if ((this.getRow() == loc <http://jakarta.apache.org/poi/javadocs/javasrc/org/apache/poi/hssf/record/NumberRecord_java.html#NumberRecord.equals.loc>.getRow <http://jakarta.apache.org/poi/javadocs/javasrc/org/apache/poi/hssf/record/CellValueRecordInterface_java.html#CellValueRecordInterface.getRow%28%29>())
353 && (this.getColumn() == loc <http://jakarta.apache.org/poi/javadocs/javasrc/org/apache/poi/hssf/record/NumberRecord_java.html#NumberRecord.equals.loc>.getColumn <http://jakarta.apache.org/poi/javadocs/javasrc/org/apache/poi/hssf/record/CellValueRecordInterface_java.html#CellValueRecordInterface.getColumn%28%29>()))
354 {
355 return true;
356 }
357 return false;
358 }
359
http://jakarta.apache.org/poi/javadocs/javasrc/org/apache/poi/hssf/record/NumberRecord_java.html#NumberRecord
meaning we can easily check the instance type and return false... no
need for a special ObjectFlavor class. KISS.
-Andy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Morphos] Proposal for new interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Andrew C. Oliver wrote:
>>
>> We cannot have the SAX pipeline do something, give me an intermediate
>> result, then restarted by giving the intermediate result back, etc.
>>
>> You can do it with Stream Pipelines, because you call the first
>> Morpher on a Stream, serialize the output to a File, then give that
>> file to another Morpher... etc.
>
> Oh god that sounds slow and you can't do that with HSSF. Don't think in
> terms of files.
If you have a server that is overloaded, you cannot have a thread per
request, you need to stop processing of some requests for some time and
continue later; in this case I can store the result somewhere (in RAM,
if not file), and do it later, preemptively.
>>
>> Yes, we need this.
>>
>> I propose:
>>
>> boolean canMorph(ObjectFlavor input, ObjectFlavor output) {
>> ...
>> }
>>
>> It's better be because if input is a Stream, it's too generic to
>> understand if it can work on it.
>>
>> ObjectFlavor[] getSupportedInputFlavors()
>> ObjectFlavor[] getSupportedOutputFlavors()()
>>
>> A morpher could support multiple ObjectFlavors.
>>
> Why ObjectFlavor?
"
>> It's better be because if input is a Stream, it's too generic to
>> understand if it can work on it.
"
If I ask the POI morpher, "can you transform a contenthandler into a
stream"?
Reply : yes.
Then I give it a gif image in the streams and it breaks horribly.
> I don't see a need for this, there is already support
> for doing this in the JDK and code examples (anything using the
> compareable intereface).
Compareable?
Me no understand...
In JDK there is java.awt.datatransfer.DataFlavor, but you know what it
means to have an awt import...
...also something similar is there for ptinting, but they are simply
overspeced and bloated.
What examples are you talking about?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Morphos] Proposal for new interface
Posted by "Andrew C. Oliver" <an...@superlinksoftware.com>.
>
> We cannot have the SAX pipeline do something, give me an intermediate
> result, then restarted by giving the intermediate result back, etc.
>
> You can do it with Stream Pipelines, because you call the first
> Morpher on a Stream, serialize the output to a File, then give that
> file to another Morpher... etc.
Oh god that sounds slow and you can't do that with HSSF. Don't think in
terms of files.
>
> Yes, we need this.
>
> I propose:
>
> boolean canMorph(ObjectFlavor input, ObjectFlavor output) {
> ...
> }
>
> It's better be because if input is a Stream, it's too generic to
> understand if it can work on it.
>
> ObjectFlavor[] getSupportedInputFlavors()
> ObjectFlavor[] getSupportedOutputFlavors()()
>
> A morpher could support multiple ObjectFlavors.
>
Why ObjectFlavor? I don't see a need for this, there is already support
for doing this in the JDK and code examples (anything using the
compareable intereface).
-Andy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Morphos] Proposal for new interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Andrew C. Oliver wrote:
>>
>> I'd say, let's ditch Locator and have simply URLS up front for
>> Morphos.java.
>> And remember that Morphers must Morph stuff, not identify and locate
>> stuff.
>>
>> URL = UR*Locator* ;-)
>
>
> Let someone else LOCATE.
Yes, but Morphos.java is just the CLI.
We obviously need to locate here, and URLs are simple to use for it.
> Just take the *stream*
Not only streams, it can be also DOM, contenthandlers, etc.
>and assume someone
> located whatever
> in advance.
>>>
>>> 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.
>
>
> Explain what you mean by it.
>
>>
>>> 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.
>
>
> Oh okay I think I get it. Thats fine.
>
>>
>>> 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 invocations.
>>
>> So I guess that SAX pipelines will always have to be treated atomically.
>
> eh?
We cannot have the SAX pipeline do something, give me an intermediate
result, then restarted by giving the intermediate result back, etc.
You can do it with Stream Pipelines, because you call the first Morpher
on a Stream, serialize the output to a File, then give that file to
another Morpher... etc.
>>> (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.)
>>
>> 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){
>> }
>> }
>>
>> and
>>
>> abstract class SimpleMorpher
>> {
>> morph(Object input,
>> Object output){
>>
>> morph(input,
>> output,
>> new nullErrorHandler,
>> new HashMap();
>> }
>>
>> setConfigutarion(Map conf){
>> }
>>
>> }
>>
> With this we also need:
>
> boolean validate(Object input, Object output) {
> boolean retval=false;
> if (input instanceof InputStream && Output instanceof OutputStream) {
> retval = true;
> }
> return retval;
> }
>
> and perhaps
>
> Class getInputType()
>
> Class getOutputType()
>
> or some way of figuring out "what does this thing do".
Yes, we need this.
I propose:
boolean canMorph(ObjectFlavor input, ObjectFlavor output) {
...
}
It's better be because if input is a Stream, it's too generic to
understand if it can work on it.
ObjectFlavor[] getSupportedInputFlavors()
ObjectFlavor[] getSupportedOutputFlavors()()
A morpher could support multiple ObjectFlavors.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Morphos] Proposal for new interface
Posted by "Andrew C. Oliver" <an...@superlinksoftware.com>.
>
> I'd say, let's ditch Locator and have simply URLS up front for
> Morphos.java.
> And remember that Morphers must Morph stuff, not identify and locate
> stuff.
>
> URL = UR*Locator* ;-)
Let someone else LOCATE. Just take the *stream* and assume someone
located whatever
in advance.
>>
>> 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.
Explain what you mean by it.
>
>> 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.
Oh okay I think I get it. Thats fine.
>
>> 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 invocations.
>
> So I guess that SAX pipelines will always have to be treated atomically.
eh?
>
>> (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.)
>
>
> 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){
> }
> }
>
> and
>
> abstract class SimpleMorpher
> {
> morph(Object input,
> Object output){
>
> morph(input,
> output,
> new nullErrorHandler,
> new HashMap();
> }
>
> setConfigutarion(Map conf){
> }
>
> }
>
With this we also need:
boolean validate(Object input, Object output) {
boolean retval=false;
if (input instanceof InputStream && Output instanceof OutputStream) {
retval = true;
}
return retval;
}
and perhaps
Class getInputType()
Class getOutputType()
or some way of figuring out "what does this thing do".
-Andy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Morphos] Proposal for new interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Andrew C. Oliver wrote:
> 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.
I'd say, let's ditch Locator and have simply URLS up front for Morphos.java.
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
invocations.
So I guess that SAX pipelines will always have to be treated atomically.
> (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.)
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){
}
}
and
abstract class SimpleMorpher
{
morph(Object input,
Object output){
morph(input,
output,
new nullErrorHandler,
new HashMap();
}
setConfigutarion(Map conf){
}
}
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Morphos] Proposal for new interface
Posted by "Andrew C. Oliver" <an...@superlinksoftware.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Morphos] Proposal for new interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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).
> 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?
> 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''
>>
>>
>
>
>
>
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>