commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <>
Subject Re: [Morphos] Proposal for new interface
Date Fri, 06 Sep 2002 14:40:09 GMT
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 

>>> 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 <>(Object
345      {
346          if (!(obj <>
instanceof CellValueRecordInterface))
347          {
348              return false;
349          }
350          CellValueRecordInterface <>
loc = ( CellValueRecordInterface ) obj <>;
352          if ((this.getRow() == loc <>.getRow
353                  && (this.getColumn() == loc <>.getColumn
354          {
355              return true;
356          }
357          return false;
358      }

meaning we can easily check the instance type and return false...  no 
need for a special ObjectFlavor class.  KISS.


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

View raw message