[e-lang] Understanding Descs

[William ML Leslie]

​Is the following a reasonable thing to do in DataE?​
(DescMaker <- NewFar(
​7​
, "x")) <-
__whenMoreResolved(someObType <- new(
DescMaker <- NewFar(
​8​
, "y"), some_data))
​That is: I allocate​
​ refs that allow two-way communication. I (who sent this message) can
call methods on your proxy someObType by sending to export 7, and you can
call methods on my original someObType​
by sending to import 8.​
​Just trying to understand the Descs in CapTP,​
--
William Leslie
Likely much of this email is, by the nature of copyright, covered under
copyright law. You absolutely MAY reproduce any part of it in accordance
with the copyright law of the nation you are reading this in. Any attempt
to DENY YOU THOSE RIGHTS would be illegal without prior contractual
agreement.
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Kevin Reid]

​Is the following a reasonable thing to do in DataE?​
(DescMaker <- NewFar(​7​, "x")) <-
__whenMoreResolved(someObType <- new(
DescMaker <- NewFar(​8​, "y"), some_data))
​That is: I allocate​​ refs that allow two-way communication. I (who sent this message) can call methods on your proxy someObType by sending to export 7, and you can call methods on my original someObType​ by sending to import 8.​

Dusting off my knowledge...

First, a nitpick: Descs are not in Data-E per se, they are in CapTP (which does contain references to descs in its _application_ of Data-E). Your question is entirely about CapTP.

Your use of <- is incorrect: all Data-E calls are ".". (Well, except where they can't be due to circularity.) Therefore, the __whenMoreResolved is redundant because a far ref is fulfilled the moment it exists.

What your description will do is execute someObType.new(...) on the remote end, then immediately _call it as a function_ (because that's what whenMoreResolved does with its parameter) with far ref 7 as an argument.

I think you actually wanted this (fixing terminology as well as structure):

DescMaker.NewFar(7) <- run(makeSomeOb(DescMaker.NewFar(8), someData))

(<- isn't a Data-E primitive, but it can be indirectly expressed via E.send just as it is in normal E. "run" is the function-call method name.)

This will achieve your original goal, roughly (assuming that you're locally allocating index 8 to "my original"). However, 7 isn't itself a reference to the remote presence -- it's a local-to-"you" function that gets called with that reference.

However, if one just does this in vaguely normal fashion in user-level E -- actually, there isn't quite a "normal way to do it" since we don't have the "where" block MarkM proposed. OK, so just addressing the best way to do it in CapTP -- you wouldn't use far ref 7, instead you would send a DeliverOp which allocates a _question_.

Deliver(-9, <redirector>, 10, "run", [DescMaker.NewFar(8), someData])

where:
-9 is the new locally-allocated question index
<redirector> is approximately a resolver for the local promise
10 is the index of the remote makeSomeOb (which would be
gotten by a previous Deliver op getting it from wherever
it came from -- that's what promise chaining does)
and the next two args are the message being sent.

At least, I think I've gotten it right. It's been a while since I've worked on CapTP.

(If you're trying to construct an Unum, you probably will want it to have two facets -- one for inter-presence communication and one for the public interface -- but that can be done after this setup.)

[William ML Leslie]

On 14 January 2015 at 17:52, William ML Leslie <

​Is the following a reasonable thing to do in DataE?​
(DescMaker <- NewFar(​7​, "x")) <-
__whenMoreResolved(someObType <- new(
DescMaker <- NewFar(​8​, "y"), some_data))
​That is: I allocate​​ refs that allow two-way communication. I (who

sent this message) can call methods on your proxy someObType by sending to
export 7, and you can call methods on my original someObType​ by sending to
import 8.​
Dusting off my knowledge...

​Thanks Kevin. I've been reading the source of caja-captp to turn my
ad-hoc, buggy custom implementation of CapTP on Twisted into something I
can share. It's nice to have a working implementation to read and test
against, although I still struggle with some of the terminology (which,
despite being very unique, is yet not searchable online: have you ever
googled "E unum" ?) especially in trying to support patterns that I've used
in the past. I'll surely have a few more questions to ask.

instead you would send a DeliverOp which allocates a _question_.

For my own reference: allocates a question on the sending side, and a
corresponding answer​ on the receiving side.
​​

Deliver(-9, <redirector>, 10, "run", [DescMaker.NewFar(8), someData])
-9 is the new locally-allocated question index
<redirector> is approximately a resolver for the local promise

10 is the index of the remote makeSomeOb (which would be

gotten by a previous Deliver op getting it from wherever
it came from -- that's what promise chaining does)
and the next two args are the message being sent.
At least, I think I've gotten it right. It's been a while since I've worked on CapTP.

​Looks sensible, thanks. It does mean that a single app-level send
containing an Unum means sending several additional messages, but I can
live with that.

(If you're trying to construct an Unum, you probably will want it to have
two facets -- one for inter-presence communication and one for the public
interface -- but that can be done after this setup.)

​Good idea.

​

[Kevin Reid]

Post by Kevin Reid

​Is the following a reasonable thing to do in DataE?​
(DescMaker <- NewFar(​7​, "x")) <-
__whenMoreResolved(someObType <- new(
DescMaker <- NewFar(​8​, "y"), some_data))
​That is: I allocate​​ refs that allow two-way communication. I (who sent this message) can call methods on your proxy someObType by sending to export 7, and you can call methods on my original someObType​ by sending to import 8.​

Dusting off my knowledge...
​Thanks Kevin. I've been reading the source of caja-captp to turn my ad-hoc, buggy custom implementation of CapTP on Twisted into something I can share.

If I recall correctly, caja-captp is less complete than the CapTP in E-on-CL. I'd recommend you read the latter instead — I know it actually works for two-party communication. (Unfortunately, I didn't finish wiring it up to VatTP, so it never ran over an actual network.)

Post by Kevin Reid
​Looks sensible, thanks. It does mean that a single app-level send containing an Unum means sending several additional messages, but I can live with that.

Yes. However, in an E system, the __optUncall (serialize hook) of the local unum presence would not actually be doing these extra messages itself, or using this pattern at all, I think. (Because it doesn't and can't _have_ a reference to the remote presence at all.)

Instead, the remote constructor for the unum presence (which could be mobile code or not, doesn't matter) would, when invoked on the remote side, send a message back over one of its arguments (which is a facet of the original presence) to establish the two-way communication.