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: Proposed interfaces for InfoMover
Date Fri, 16 Aug 2002 15:26:09 GMT
> From: kevin.s.ruland@mail.sprint.com 
> 
> Berin,
> 
> I think it's unnatural for the job to have to worry about
> how many manipulators are in the chain.  Instead, it should 
> only worry about taking transactions from the input and 
> putting them in the output.  If the output happens to be a 
> manipulator, then it should worry about pushing the 
> transaction down the pipe.

Its easy enough to automate cycling through the manipulators.
I expanded the logic to show how it would deal with each instance.

> 
> So the Job would have one input and one output and do the following:
> 
> while ( ( transaction = input.getNextTransaction() ) != null ) {
>     resp = m_output.process( transaction );
>     m_notifier.handleResponse( resp );
> }
> 
> If m_output happens to be a manipulator then it would do:
> 
> Output:
> 
> Response process( Transaction t ) {
> 
>   Transaction newTransaction = do_what_this_needs_to_do_to(t);
> 
>   if (newTransaction == null) {
>     return new Response( ROLLBACK, t );
>   }
> 
>   return m_output2.process( newTransaction );
> 
> }

That seems reasonable, but it also requires the registration
method for the next stage.

What did you think about the Morphos proposal?

My spin is that I want to document creating components, and
have an easy to use system without adding too many dependencies.
I would have to document the Morphos system as well, which I
am not prepared to do at this time.  I think it would be perfectly
valid after we cut the Version 1 ( aka book version ), but
until then I need to keep the system really simple.


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