Berin Loritsch wrote:
So far, there are essentially three different proposals, two by me and one by Nicola. I will enumerate the advantages and disadvantages of each.
--------- From Nicola (Morpher interface) ----------
public interface Morpher { void setInput(Object input) throws ObjectFlavorException; void setOutput(Object output) throws ObjectFlavorException; void morph() throws MorphException; }
public interface MorpherPipeline extends Morpher { void addStage(Morpher nextMorpher); }
------------------ NOTES -----------------
* The bidirectional registration ( setInput(), setOutput() ) seems unnecessary. A pipeline flows in one direction--from the input to the output. Our API should reflect that.
Initially it was just
morph(input, output)
but it was showed how the setup and generation phases had to be separate to be able to pipeline streams and events correctly.
Also, sometimes the input or the output are not used, hence the separate methods.
* The MorpherPipeline (or equiv.) interface may make it easier to add stages, but InfoMover's logic is pretty simple. It the pipeline can safely be implicit instead of explicit. We have no need of caching pipelines or other more esoteric solutions. IMO they are FS. If we need to cache, that should be designed intelligently into the system.
It's about SOC, so that Pipelines assemble Morphers. It's a conceptual layer that works pretty well IMHO.
* There is no distinction between Input, Output, and Manipulator. I think that these should have a definite distinction.
The Manipulator is the Morpher.
The input and output are just Objects because the Morpher is gotten from a factory.
So basically I don't have Input and Output objects but just Objects, similarly to Services not needing Components to work.
* Required method ordering precludes the ability to have ThreadSafe implementations, which can cause resource strains on a loaded system. I don't want to be a victim of those issues if I can help it.
Hmmm...
*This* is a valid point... I assumed that a Morpher wasn't a service, but could be used by a service...
This needs more thinking...
* The morph() method doesn't make sense in this context.
Ok ;-)
----------- From Me (First Version) ---------
interface Input { void setDestination( Output out ); }
interface Output { Response processTransaction( Transaction trans ); }
interface Manipulator extends Input, Output {}
---------------- NOTES -----------------
* Requires registration, but it is unidirectional. Still Manipulators can't be threadsafe.
* as Nicola pointed out, setDestination() is not intuitive
* The more I look at it the less I like it
;-)
------------ From Me (Second Version ) -----------
interface Input { Transaction getNextTransaction(); }
interface Output { Response process( Transaction trans ); }
interface Manipulator extends Input, Output {}
------------------ NOTES -----------------------
* Does not require any registration of the next stage in the pipeline
* It is more intuitive to use
* The Job is in finite control of the pipeline
* Manipulator still has issues with threadsafe implementations, and worse, if the calls to process() and getNextTransaction() are not symetrical we can get some weird runtime errors--so that is a blocker.
Yup :-(
---------------- From Me (Third Version) --------------
interface Input { Transaction getNextTransaction(); }
interface Output { Response process( Transaction trans ); }
interface Manipulator { Transaction manipulate( Transaction trans ); }
----------------- NOTES -------------------
First not from me... at a first glance I don't get it...
...thinking...
...but it seems that you have solved the threadsafe problem by putting the extra methods needed to setup first and then execute in different objects... interesting...
So instead of having one object with three methods to call in order, we have three objects each with an atomic method.
I'm still not sure if this is clever or just illusionism 8-) but still thinking...
* has all the strengths of the second version, but finally gets rid of the method ordering issues.
yes, I saw this...
* The Manipulator does what it does best, manipulates a transaction.
Unfortunately we have no way of extracting a Response if the
transaction
violates some integrity checking issues.
- We can create a "struct" like class that encapsulates the
Transaction
and Response together, allowing us to keep the same strengths and
check
if the transaction is still good.
- We can alter the Transaction so that we can make the Response
encapsulated
inside the Transaction. That would cut down on Response object
creation,
and still let us know if the transaction was successful. This is
probably
the better of the two solutions.
Yes, this last point is what I thought of too, that there should not be a separate response...
BTW, this method
Response process( Transaction trans );
is not what we would use in Morphos, since if we want to make data flow from one Stream to another I need two parameters in input, not only one.
I'm starting to get a bit dizzy with this last proposal @-|
I need to process an Object into another Object. Your interfaces are not clear in this respect. Can you show me some code how it could be used?
Here is an example from Morphos.java:
InputSource input = new InputSource(new
FileInputStream(args[0]));
OutputStream output = new FileOutputStream(args[1]); MorpherFactory mf = new BasicMorpherFactory();
MorpherPipeline mp = new SAXMorpherPipeline();mp.addStage(mf.getMorpher("is2sax"));
Morpher xslt = mf.getMorpher("xslt");
if(args.length==3){
((StylesheetAware)xslt).setStylesheet(new javax.xml.transform.sax.SAXSource(new InputSource(new FileInputStream(args[2]))));
}
mp.addStage(xslt);
mp.addStage(mf.getMorpher("gnumeric2xls"));
mp.setInput(input);
mp.setOutput(output);
mp.morph(); output.flush();
output.close();
-- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) ---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
