localhost_frssoft/ocappub
1
0
Fork 0
mirror of https://gitlab.com/spritely/ocappub.git synced 2024-11-22 21:23:02 +00:00
Code Issues Projects Releases Wiki Activity

Add the "Composition" section

Browse Source
This commit is contained in:
Christopher Lemmer Webber 2019-07-31 09:44:11 -04:00
parent ba6a0eaa72
commit 1d826f33ed
No known key found for this signature in database
GPG Key ID: 4BC025925FF8F4D3
1 changed files with 76 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

76
README.org
View File

@ -1395,6 +1395,82 @@ tonight.
# add backup of file example; alice's composed capability should # add backup of file example; alice's composed capability should
# live on her own server # live on her own server
One thing we might notice about the previous example is that we said
that Alyssa set up the endpoint pointed by the capability to "log"
information about who was associated with it.
But... where did the logger come from?
The file did not contain this functionality, and capabilities
themselves do not intrinsically have logging functionality.
The answer is: Alyssa had a capability to a logging facility, and used
that to do the logging!
But what's interesting about that?
Think about it for a moment: the capability is now doing something more
interesting than mere "proxying".
It isn't merely forwarding or not a message to a single capability...
Alyssa has *composed together* the file capability with the logging
capability.
Pretty cool!
And yet we are about to see an even cooler example of composition.
Now that Alyssa has put enough work into this file, she would like to
automatically back up the file's contents twice a day.
Luckily, she has a capability to a job-scheduling service:
: # lets Alyssa schedule work at periodic intervals
: # aka <JOB-SCHEDULER>
: https://webchronjobs.example/api/3Gw5Ivk_qaNPLWro0MTr_KP1JhuC6GWDvhgDARFG61g
Alyssa also has a capability to a backup service:
: # more or less another place to put files
: # aka <BACKUP-SERVICE>
: https://backups.example/api/BUWRNHd2kIkhl0MvtPUd8tqhW_c99c5KdBZYC7bC0NA
And recall, of course, Alyssa's original capability to <PARTY-FILE>
: # aka <PARTY-FILE>
: https://filestore.example/obj/30SVLFRf1cTPNnjgaJfN8r85joIMVDSgWSKXKoYiFuY
Alyssa would like to have =<JOB-SCHEDULER>= periodically copy
=<PARTY-FILE>= over to =<BACKUP-SERVICE>=.
However, she wouldn't like =<JOB-SCHEDULER>= to be able to read
the contents of =<PARTY-FILE>= or write anything else other than
the backup of =<PARTY-FILE>= to =<BACKUP-SERVICE>=.
This might seem like an impossible task... but Alyssa knows how
to do it.
Alyssa creates a new object/endpoint on her own server with the
following capability URL:
: # aka <BACKUP-PARTY-FILE>
: https://alyssas-home.example/obj/9SzcK9U40-EPYll1ixTU2-jgqvPWJy1xvQWfSp3aT-c
Now here's the cool thing: internally, =<BACKUP-PARTY-FILE>= knows
about and actually uses both =<PARTY-FILE>= and =<BACKUP-SERVICE>=...
it's just some simple code that reads the current state of
=<PARTY-FILE>= and copies it over to =<BACKUP-SERVICE>=; that's it.
But =<BACKUP-PARTY-FILE>= never /discloses/ the locations of either
=<PARTY-FILE>= or =<BACKUP-SERVICE>=.
Why should it?
And so, Alyssa can schedule =<JOB-SCHEDULER>= to run
=<BACKUP-PARTY-FILE>= twice a day.
But =<JOB-SCHEDULER>= never gets to read the actual contents of
=<PARTY-FILE>= or write anything else to =<BACKUP-SERVICE>=
(it doesn't even know where either live).
This is the Principle of Least Authority in action!
You may also notice that all four of the capabilities in this section
were on different servers.
And yet there was no trouble coordinating authority between them.
The servers really did not need to "think" about which servers, or
which users, had access to what.
This all just fell out of the design of the system, the same way
that data naturally flows through the code pathways of our programs
through argument passing.
**** Mapping this to ActivityPub **** Mapping this to ActivityPub