search

node-task / spec

A specification for javascript tasks.
MIT License
153 stars 2 forks source link

Piping #7

Closed jgable closed 11 years ago

jgable commented 11 years ago

Thanks for the work on grunt, and for the initiative to get a standard task structure defined.

I'd like to open a conversation about the possibility of piping the results of tasks to other tasks. It seems like I've had a hard time with putting the results of a task in a temporary location, then running another task on that location.

An example would be a situation where I want to concatenate the scripts in each folder to a single script with that folders name, then minify/uglify then upload to s3.

Could this perhaps be something that the task can opt into by emitting some scoped events like "pipe.data" and "pipe.end"?

Just a thought, definitely open to suggestions.

sindresorhus commented 11 years ago

I've brought this up before and I agree. It would also reduce disk IO as you wouldn't have to write to disk, read, then write again.

tkellen commented 11 years ago

I will respond to this more thoroughly later (out for birthday dinner), but I agree 1000% and this is built into the spec already, that is what filterRead and filterWrite are for.

On Feb 21, 2013, at 4:25 PM, Sindre Sorhus notifications@github.com wrote:

I've brought this up before and I agree. It would also reduce disk IO as you wouldn't have to write to disk, read, then write again.

— Reply to this email directly or view it on GitHubhttps://github.com/tkellen/node-task/issues/7#issuecomment-13913717.

satazor commented 11 years ago

Please note that piping should not be restricted to IO coming from files, since a task might want to emit data that does not come from files. Having this in mind, the piping should not be tight coupled with file operations.

The @jgable suggestion about having standard events for emitting/piping data might be a good approach.

sindresorhus commented 11 years ago

Having this in mind, the piping should not be tight coupled with file operations.

Of course not, that was only an example of a benefit of it. It should just be buffers of data.

satazor commented 11 years ago

@sindresorhus With my last comment, I wanted to say that the spec should not rely on filterRead/filterWrite for handling incoming/outgoing data. The current description of these properties in the spec is tight coupled with files. It should be more generic/abstract.

satazor commented 11 years ago

Also, I've not yet read with detail the part of the spec that specifies how files are handled. I'll need to analyse the current proposal with greater detail to give more feedback on it.