On 22 Jun 2009, at 09:32, Stian Soiland-Reyes wrote: > On Sat, Jun 20, 2009 at 01:04, Jan Hidders<[email protected]> > wrote: >>> An iteration cannot start before all the control links are satisfied >>> AND all the input ports have received a value for that iteration. >> Just to be clear: when you say "have received a value" do you mean >> that they have received a complete value, or that they have received >> it partially for at least one index? > > Received *completely* for at least one index, and that would be the > index that would be started. You can't have a partial start - for > instance a WSDL service can't start with only 2 of 3 parameters ready, > there's no way we can tell the web-service later that 'Ohh.. and the > third parameter is Fish' while it's in the middle of it's > calculations. :)
Understood, but for a nested workflow this would in principle be possible, so we need to explicitly state this in the formal semantics. So it will now say that if a processor iterates over [["a","b"],[], ["c"]] the iteration for position 1 will not start until the messages for position 1.1 (the string "a"), position 1.2 (the string "b") and position 1 (closing the list). This would be correct, yes? > >> So when exactly is the empty index returned? Is this after each >> iteration has produced its complete output, or after each iteration >> has completed all its activities? > > After each iteration has produced its complete output. It is true that > if the activity is a nested workflow, that nested workflow might still > be running even if all the values for the output ports have been > produced, but I believe we could consider that a bug. Not totally sure > about that, but all other activity types are 'finished' once they have > returned values. (Asynchronous services are different as they > continue running server-side, but you would then have other methods in > to check the status and get the results) Clear. We will let the formal semantics say that after the last output message from a certain iteration for a certain position there is no more activity going on in the iteration for that position. >> Do you just mean to say here that all output ports always produce >> values, or are you talking about synchronization here, i.e., they >> produce it more or less at the same moment? > > They would all produce values, and the values would come at exactly > the same moment - the values are returned in a Map that flows up the > dispatch stack - at the top of which the Processor will disassemble it > and send it out on the individual processor output ports. But didn't you want to allow pipelining through the dispatch stack such that some services could actually return their result in a stream? We took a lot of trouble to adapt the formal semantics such that we could describe this and this makes a few things more complicated. So it is quite important for us to know what you want the formal semantics to say here. -- Jan Hidders ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org _______________________________________________ taverna-hackers mailing list [email protected] Web site: http://www.taverna.org.uk Mailing lists: http://www.taverna.org.uk/taverna-mailing-lists/ Developers Guide: http://www.mygrid.org.uk/tools/developer-information
