[alex_d]

"Why communicate over the filesystem when you can communicate much more clearly via code?"

Using folders as pads is a bit dirty (especially for concurrent conversions... although those should really be batched and run sequentially anyway) but it is _somewhat_ elegant and, above all, _very_ easy to hook into and extend.

Say I have a program that can be told from the command-line to accept some input files and create some output files. How would I integrate it into your framework?

"PDFRead has no such limitation, and I think that supporting (simultaneous) batch processing is very important."

Actually, I think batching serially rather than concurrently makes more sense. You get your first output quicker and there is no problem if you want to convert an obscene number of files. (Even a few dozen concurrent conversions would kill the ram).

"If each layer exposes enough features to turn on/off features individually, the command line options for it will grow quite a bit (see PDFRead). "

Well, the command line options wouldn't be for the user to use but for the developer writing a wrapper. Surely it'll be much easier on (and give more freedom to) a developer to code a long command line in his script than to output a custom pipeline file?


In the end, though, there are two questions: Can a sophisticated framework of which you speak be implemented in theory (ie is the concept compatible with being very flexible and easy to extend)? And: Will such a framework be actually implemented by us (ie will it be too much work)? The folders approach, I think, has both points going for it.

I must say, however, I like the cut of jib.