[Fwd: Re: [Morphos] Proposal for new interface]

[Nicola Ken Barozzi <ni...@apache.org>]

Andrew C. Oliver wrote:
 > 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.

Look at the SEDA architecture for web servers.
They claim to be able to have a much higher scalability than
thread-based servers.

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

ObjectFlavor contains also the mime/type, it's called datatype:

http://cvs.apache.org/~nicolaken/morphosUML/p_xmi_125_diagram.html

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

Yes, it's similar to the Locator stuff issue.

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

The mime/type, man, you said it above.

We need a way for the pipeline to know what is the datatype-dataform
combination that is coming, so it's able to assemble itself.

SAX pipelines are different from stream ones.


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