Remove implicit_init from the WorkContext

[johny-b]

resolves #649

Also: fixes current problem with services without start() method.

[shadeofblue]

added some suggestions, otherwise, I think it's okay

[kmazurek]

These two calls add commands to the internal Script instance kept by a WorkContext. When the non-deprecated way of creating scripts is used (i.e. calling new_script on the WorkContext and adding steps to that Script) in the requestor application, these commands will end up never being called.
One option I can think of is to perform the implicit init in WorkContext#new_script and use an internal bool flag to check whether deploy/start should be added to the newly returned Script instance.

[johny-b]

:(

[johny-b]

Fixed in bc86bae, hopefully.

[johny-b]

I've chosen other solution than proposed because now everything is still in Executor, without any implicit-init related things in WorkContext and I think there's some value in having this in a single place.

[shadeofblue]

the issue I have is that we're adding overhead of sending two batches (one with the init, and one with commands coming from the client code) instead of just one, where the user script is prepended with the init

[johny-b]

the issue I have is that we're adding overhead of sending two batches (one with the init, and one with commands coming from the client code) instead of just one, where the user script is prepended with the init

Do you know any reason why this should be harmful?
But well, I'd also prefer to avoid this, but not at a cost of putting this stuff in WorkContext.

Maybe a simple solution would be to merge those two batch generators into a single one? I tried that first, but this was too hard for me :/ But I could give it another try if you think this is important.

[shadeofblue]

the issue I have is that we're adding overhead of sending two batches (one with the init, and one with commands coming from the client code) instead of just one, where the user script is prepended with the init

Do you know any reason why this should be harmful?
But well, I'd also prefer to avoid this, but not at a cost of putting this stuff in WorkContext.

Maybe a simple solution would be to merge those two batch generators into a single one? I tried that first, but this was too hard for me :/ But I could give it another try if you think this is important.

harmful might be too strong a word, rather potentially suboptimal performance-wise...

[johny-b]

the issue I have is that we're adding overhead of sending two batches (one with the init, and one with commands coming from the client code) instead of just one, where the user script is prepended with the init

Do you know any reason why this should be harmful?
But well, I'd also prefer to avoid this, but not at a cost of putting this stuff in WorkContext.
Maybe a simple solution would be to merge those two batch generators into a single one? I tried that first, but this was too hard for me :/ But I could give it another try if you think this is important.

harmful might be too strong a word, rather potentially suboptimal performance-wise...

As far as I understand the Executor/Engine code, this makes ~~ 0 difference from the performance POV.

[shadeofblue]

the issue I have is that we're adding overhead of sending two batches (one with the init, and one with commands coming from the client code) instead of just one, where the user script is prepended with the init

Do you know any reason why this should be harmful?
But well, I'd also prefer to avoid this, but not at a cost of putting this stuff in WorkContext.
Maybe a simple solution would be to merge those two batch generators into a single one? I tried that first, but this was too hard for me :/ But I could give it another try if you think this is important.

harmful might be too strong a word, rather potentially suboptimal performance-wise...

As far as I understand the Executor/Engine code, this makes ~~ 0 difference from the performance POV.

it's not about Executor/Engine - it's about provider <-> requestor communications....