- From: Conal Tuohy <conal.tuohy@versi.edu.au>
- Date: Tue, 15 Mar 2011 14:02:19 +1100
- To: Alex Muir <alex.g.muir@gmail.com>
- CC: vojtech.toman@emc.com, xproc-dev@w3.org
- Message-ID: <4D7ED6BB.4000103@versi.edu.au>
On 15/03/11 03:19, Alex Muir wrote: > I wonder why one wouldn't generally want the steps to execute one > after the other unless specified otherwise in someway by the script to > for example execute in parallel or to execute and not wait? Personally I wouldn't want to have to state "these pipelines can execute in parallel". As a programmer I want to focus on what are the logical dependencies between my pipelines, and any given pipeline processor can work out for itself whether or not it can execute them in parallel. I also don't want to have to physically allocate space on disk to store my files, and I don't want to have to do error correction on my network connections; it's a similar principle I think. A pipelining language should make parallelisation easy for the programmer, and not require you to manage it explicitly (in the general case). The issue arises where you have dependencies that are not captured in your code (i.e. step A has to execute before step B, but the dependency isn't captured in the XProc script because, as in the example case, it only exists in the form of a data file in a file system external to the pipeline). In that case, I think Norm's right that the most obvious solution is just to "pipe" those steps together, e.g. by "piping" the location of the file from the source to the destination. -- Conal Tuohy eResearch Business Analyst Victorian eResearch Strategic Initiative +61-466324297
Received on Tuesday, 15 March 2011 03:02:59 UTC