Berin Loritsch wrote:
One step at a time Nicola.  The important thing is finding
what works for InfoMover.  Don't abstract too early.  Lets
learn from a working system.

Yes, mine are RTs.

By showing the fact we *could* call them Objects, it allowed
you to show that it is a processing pipeline that works on an
Object Model.

Exactly what I wanted to show :-)

One important thing to look at is that we have a special purpose
object model because we have a special purpose need.  As we find
commonalities, we can look at finding the abstraction that works
generically.  However, we won't be able to do that until we find
the boundary constraints.

Yes. I am abstracting now because I want to find common ground (where it's pertinent) between infomover and morphos.
I see that this discussion isreally helping also morphos :-)


I personally dislike things that are so ill defined that they
could be mis-used for anything.  We have a predefined object
model to make it easier to write the components for it.

I understand, for me it's ok.
Now I see how Morphers and Manipulators are different, but this is not a problem.
Once the InfoMover system is set up, we can always taks lessons and just implement Jobs that use Morphers instead of Manipulators.



-----Original Message-----
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] Sent: Sunday, August 18, 2002 9:00 AM
To: Avalon Applications Developers List
Subject: Re: InfoMover Interfaces: the Proposals




Leo Simons wrote:

On Sat, 2002-08-17 at 04:40, Peter Donald wrote:


On Sat, 17 Aug 2002 04:18, Berin Loritsch wrote:


---------------- From Me (Third Version) --------------

interface Input
{
  Transaction getNextTransaction();
}

interface Output
{
  Response process( Transaction trans );
}

interface Manipulator
{
  Transaction manipulate( Transaction trans );
}

+1


+1

>

Essentially makes it event driven and the controller that

drives this

has a
lot more control, the objects are largely reactive etc.

It is great if you want to massively scale but possibly a little harder to
write initially (though I find even style programs easier

to write so I find

this easier ;)


the correct definition of Transaction and Response is very

important


as well; you'll also want well-defined Input-Output translation defined (in many IO-related systems it is way more complicated to couple some input to some output than it should be) as part of the core feature set.

As I recall from a mail from Berin, we have:

Input: it brings information
Manipulator: it acts on the information
Output: endpoint
Job: the manager of the flow of the transaction from an Input to an Output via Manipulators.


So, instead of Transaction, let's call it object like we didi with Serviceable stuff, that is what contains the thing we are Manipulating.

interface Input
{
    Object getObject();
}

interface Manipulator
{
    Object manipulate( Object object );
}

interface Output
{
    Notifying process( Object object );
}

Ok, this I start to understand.

Example:

 interface FixedIdInput
 {
    Object getDataObject(){
       return "FIXEDID125"
    }
 }

 interface DuplicateStringManipulator
 {
    Object manipulate(Object obj){
       String objString = (String) obj;
       return objString + objString ;
    }
 }

 interface SystemOutOutput
 {
    Notifying process( Object object ){
       System.out.println(obj);
       return new Notification(Notification.SUCCESS);
    }
 }

Ok, this is very trivial, but it shows that:

1. 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 "Manipulator" for the right task, so this is not an insormontable issue.
2. How can we make SAX manipulators?
3. How can we have a pipeline with both SAX and Stream and JavaBean manipulators?


And, above all, the Manipulator 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 Manipulator?

--
Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------

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



Reply via email to