Overall brainstorm

[marcooliveira]

(follow up from https://github.com/IndigoUnited/automaton/issues/49)

Here's a list of topics that me and @satazor sorted out, after analysing the current state of the spec:

• The current doc might be a bit complicated, and worth taking a look, to ease the adoption/contribution by other developers. We feel that there are some topics that do not have the ⊄ symbol, even though they do not seem to belong to the original spec.
• We feel that the spec should define a way to specify task options. Although this is completely optional, if the user wanted to, he should provide the option names and respective descriptions. This almost makes the task self-documenting, and allows runners to provide task usage help messages.
• run method can currently provide feedback in multiple ways (sync AND promises)
  • Maybe the spec should specify a single way of doing things for consistency? (either callback, promises or events).
  • Relying on sync can lead to poor solutions, in terms of supporting parallelism, hogging the event-loop, huge callstack, and memory bloat. (even though people can rely on nextTick/setTimeout to go around this problem, it's just better to promote good practices, since not everyone will remember these issues).
  • Note that this is a spec-level definition. If a specific task builder vendor opts for simplifying task development, and also support sync, it still can. We're aware that there are a lot of people that prefer to develop this way, but the spec can be better than that, and still make everyone happy :)
  • Not committing to a single philosophy might make it hard to use tasks in a non-task way (for people looking to use a task just like a normal package). We're worried about the fact that tasks will all follow the same spec, but there are multiple ways of getting the task is done feedback, depending on what approach the task author decided to go for (from what we understood, this can either come from the fact that the task is sync, and it returned, or the task is based on promises, and we need to handle the promise).
  • Why not simply rely on the already in spec emitter, and specify a set of standard events (something like start and end, possibly a few more), that will provide feedback about what's happening? Also, a new emitter should always be created and returned when invoking run, so there is no collision between re-used tasks. (imagine using the same task twice, in parallel, would cause a conflict in the listeners, if there weren't two emitters).
• Although having a standard for tasks that handle files is good, we're not sure if this should be part of the base spec. We're aware that this is a common requirement, but the spec will be more flexible and target more environments (see the topic below), if the file handling is considered a sort of extension to the spec (still in the spec, just not in the base).
  • We still haven't taken a thorough look at the current proposal regarding file handling, so we won't comment on that yet.
• Finally, and forgive us if we're being picky, just being thorough, maybe the spec should not be called node-task? The spec can potentially be implemented in any JavaScript environment, so there's no need to limit and put that label in the spec (maybe js-task?).

Looking forward to get some feedback on this. Sorry for the long post, just wanted to be meticulous.

Also, might be a good idea to exchange Skype/GTalk contacts, so we don't pollute the repository with raw ideas (also speeds up everything).

[marcooliveira]

By the way, forgot to mention, the spec is looking promising ;)

[tkellen]

1. Docs have been updated to include a spec only.
2. Task options including defaults are now in the spec.
3. The spec now requires that run always return a promise.
4. File handling tasks have been moved to a sub-specification which I have nearly completed and will publish shortly.
5. I'm comfortable with the name node-task for now, but I see your point and will consider this.

No worries about the long post!

[satazor]

Thanks @tkellen for considering our points. Still there's a problem with the emitter being part of the task object itself. If someone tries to use a task in parallel like this:

var mincss = require('mincss-task');

mincss.run({
  files: {
    'dist/main.css': 'src/main.css'
  }
}).on('log', function () {
  console.log('something was logged when running min of main.css');
});

// And afterwards..
mincss.run({
  files: {
    'dist/panel.css': 'src/panel.css'
  }
}).on('log', function () {
  console.log('something was logged when running min of panel.css');
});

Since the emitter is common to the object itself, log events and others will collide when running the same task in parallel. This will make parallel support at the task runner somewhat difficult, specially if we got more important events that might carry data.

Like we said in the post above, this could be solved with an emitter being returned that would have start, end, log.* and maybe others (data for piping?).

[marcooliveira]

Awesome! Great to see that we see eye to eye in a lot of topics.

@tkellen

1. The spec now requires that run always return a promise.

Great to see this consistency. But consider the notes below.

@marcooliveira / @satazor:

Why not simply rely on the already in spec emitter, and specify a set of standard events (something like start and end, possibly a few more), that will provide feedback about what's happening? Also, a new emitter should always be created and returned when invoking run, so there is no collision between re-used tasks. (imagine using the same task twice, in parallel, would cause a conflict in the listeners, if there weren't two emitters).

I'm just wondering what's the reasoning behind using promises instead of the emitter. I see that the idea of using emitters or promises has been kicked around in other issues, but just wondering why the emitter did not stick. At first glance, seems like a powerful solution. /cc @millermedeiros @sindresorhus

---

I'm comfortable with the name node-task for now, but I see your point and will consider this.

Cool. If this is to happen, probably better sooner than latter, less hassle. Maybe move that into a separate issue, and have an open discussion about it? Ideas tend to get lost when we have brainstorm dumps like the one we did, and this issue now seems to be reduced to 2 open discussions :)

Final tiny note, maybe there should be a list of the task runners that are committed to contribute and support the spec? As for as I know, there is currently http://gruntjs.com/ and http://indigounited.com/automaton/

[satazor]

Bump.

[tkellen]

Just updated the spec to include the task as an instance of an event emitter. We're still going with returned promises to indicate task completion, which will make more sense when the fileReader and fileWriter specs are up.

[satazor]

@tkellen I see that spec props are now attached to the prototype . This is a good decision, since it will allow us to paralelize tasks without any problems.

Still I think you made a mistake. By doing:

var Task = module.exports = require('events').EventEmitter;
Task.prototype.bla = 'name'

We are modifying the EventEmitter protype directly. Shouldn't we use util.inherits or Object.create?

[tkellen]

Just changed that, actually :)

[satazor]

Alright thanks! The spec is looking much more clean now.

[tkellen]

:) Awesome! I'm closing this one for now. We're going to stick with node-task for the name. I'm looking forward to hearing your feedback on the fileReader/Writer additions of the spec.