RFC: Pass by Resolution

[Kris Kowal]

I am considering a new feature for the "invoke" and "call" promise methods, using a new method "pass" that would mark a promise to be passed by resolution to invocation and application messages.

https://github.com/kriskowal/q/blob/v2/test/pass-test.js

As a consequence, it would become possible to send an unresolved promise for a remote object back to a remote method invocation.

For example, this slightly hypothetical recipe would dispatch four messages to a remote file system to orchestrate copying a file.

```js

var remoteFs = remote.get("fs");

var input = remoteFs.invoke("open", "foo.txt");

var output = remoteFs.invoke("open", "bar.txt", "w");

input.invoke("pipe", output.pass());

```

Significantly, if the call to "pass()" were omitted, the input.pipe(output) remote invocation would receive a promise for output instead of the output stream itself.

Kris Kowal

[Jason Crawford]

I like this because otherwise you have to do something like

    Q.all([input, output]).spread(function (input, output) { input.pipe(output); });

It would be nice to have a better way of doing that kind of thing.

This reminds me of a presentation I saw recently Jakob Mattsson:

https://speakerdeck.com/jakobmattsson/how-to-star-actually-star-use-promises-in-javascript

He has a different way of approaching this with a promises utility library called Z:

https://github.com/jakobmattsson/z-core

I haven't tried Z out yet; would be curious to hear your thoughts.

Yours,

Jason

--
You received this message because you are subscribed to the Google Groups "Q Continuum (JavaScript)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to q-continuum...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kris Kowal]

Side discussion with MarkM reveals that I need to take a closer look at various things he’s written including:

http://erights.org/elib/equality/passing-rules.html

http://erights.org/elib/distrib/captp/DeliverOp.html

http://erights.org/elib/distrib/captp/index.html

http://erights.org/elib/distrib/captp/4tables.html

http://www.erights.org/talks/thesis/markm-thesis.pdf Chapter 19

Particularly, because it appears that "pass()" should be implicit.

Kris Kowal

[Kris Kowal]

On Sat, Mar 22, 2014 at 10:51 AM, Kris Kowal <kris....@cixar.com> wrote:

Particularly, because it appears that "pass()" should be implicit.

Nope. I’m still wrong. Using the proposed "pass" method explicitly breaks FIFO message ordering. It would not be implicit in a proper implementation. To wit

promise.invoke("method", 1);

promise.invoke("method", 2);

Guarantees that method invocation 1 and invocation 2 will occur in order in this implementation, both locally and remotely, regardless of whether "pass" is implemented. However.

promise.invoke("method", promise1.pass());

promise.invoke("method", promise2.pass());

Makes no guarantees regarding the order of execution, locally or remotely. I am uncertain whether this is a fatal flaw.

It seems that the norm with existing implementation is that the local actor must wait for the fulfillment of a remote promise with a far reference before it can send the far reference back to the remote.

remotePromise.then(function (farReference) {

    return remote.invoke("method", farReference);
});

But this will cause a round trip delay. My proposed "pass" differs from this only in that the "then" would occur remotely instead of locally, avoiding the round trip for the remotePromise to become the farReference.

I suspect it is not possible to maintain FIFO message order without that round trip. I still have a lot of reading to do.

Kris Kowal