avalon-apps-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: InfoMover Interfaces: the Proposals
Date Mon, 19 Aug 2002 12:37:52 GMT
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.

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.

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.

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.

> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org] 
> 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                   nicolaken@apache.org
>              - verba volant, scripta manent -
>     (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:avalon-apps-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:avalon-apps-dev-help@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <mailto:avalon-apps-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-apps-dev-help@jakarta.apache.org>


Mime
View raw message