Idiom for registering for a service and recieving OCaps in exchange  

  RSS

Joshy Orndorff
(@joshyorndorff)
Active Member
Joined:5 months  ago
Posts: 7
25/08/2018 2:52 am  

It's common for a user to register for a service (think microblogging, interactive tic-tac-toe), and receive an unforgeable name in return. I've thought of two ways to do this and I'm curious whether one is preferred over the other.

Here are examples of each technique

// Option 1: Caller passes in name, contract puts OCap on it
contract @"register"(controlPanel, ack) = {
contract controlPanel(x) = {
0 // Do something special here
}
|
ack!(0)
}
|
// Option 2: Contract creates name, passes it back to caller
contract @"register"(return) = {
new controlPanel in {
contract controlPanel(x) = {
0 // Do something special here
}
|
return!(*controlPanel)
}
}

ReplyQuote
MichaelBirch
(@michaelbirch)
Member Moderator
Joined:8 months  ago
Posts: 41
24/09/2018 3:35 pm  

My preference has always been the second approach. Which is preferred is perhaps a matter of taste, but I'll try to argue for why I like the second version.

1. It is much closer to a functional style. Option 1 takes an object and *modifies* it to have a new capability, while option 2 creates a new object with the capability. Favoring immutability over mutability is a more functional style choice and in general much easier to reason about.

2. The read/write permissions are controlled by the entity giving the authority. Option 1 takes a name from the outside with unknown read/write privileges, whereas option 2 creates a new name during the process and could then create a bundle from it with whatever read/write privileges make sense for the situation (in general probably write-only since the read half is the contract with the desired capability).


Will liked
ReplyQuote
  
Working

Please Login or Register