On 22 Jun 2009, at 11:55, Stian Soiland-Reyes wrote: > On Mon, Jun 22, 2009 at 10:11, Jan Hidders<[email protected]> > wrote: > > >> 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? > > > I am confused, this depends on the depth of the input ports. If input > ports are all depth 0, no invocation would be done, as the second > input port is presented with [] - iteration over an empty list yields > no iterations.
Sorry. I assumed nesting depth 1 for the port. >> 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. > > Yes, pipelining is allowed, but the service still need to provide the > data for that index on all output ports at once. We thought you meant (when we discussed pipelined services) pipelining at a lower level than the level at which the iteration happens. Let me try to explain. Assume a processor P with one input and one output port. Suppose we iterate over the list ["a", "b"]. The input port has nesting depth 1 so P iterates over the strings. Let's say for the first iteration (for value "a") the result is ["x", "y"]. for the second iteration (for value "b") the result is ["u"]. Currently we allow that the "x" can rise through the invocation stack and could even be already consumed by another processor. So we don't wait for the "y" value to arrive or the list to be closed. We assumed that this is the kind of pipelining you wanted. What we already had is that the value ["x", "y"] is produced and can be consumed by the next processor without waiting for ["u"]. -- 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
