Should HoS sections be moved/re-orgged?

Architecture Whitepapers
1

As with all documents, this one has evolved during its early drafting. Technical Sections 3.1 - 3.2 have grown considerably, and pushed the more - “explainy” sections 3.3 - 3.7 much further down the document.

We’re thinking of moving those sections up before 3.1 (and recrafting them a bit) but wanted feedback from you folks first. If you have suggestions for order of sections, please share them on this thread.

Table of Contents

  1. Introduction
  2. Capability security as ordinary programming
  3. Spritely Goblins: Distributed, transactional object programming
    3.1. A taste of Goblins
    3.1.1. A simple greeter
    3.1.2. State as updating behavior
    3.1.3. Objects which contain objects
    3.1.4. Asynchronous message passing
    3.1.5. Transactions make errors survivable
    3.1.6. Promise pipelining and coroutines
    3.1.7. Errors propagate through pipelines
    3.2. Security as relationships between objects
    3.2.1. Making and editing a blogpost
    3.2.2. A blog to collect posts
    3.2.3. Group-style editing
    3.2.4. Revocation and accountability
    3.2.5. Guest post with review
    3.3. The vat model of computation
    3.4. Turns are cheap transactions
    3.5. Time-travel distributed debugging
    3.6. Safe serialization and upgrade
    3.7. Distributed behavior and why we need it
2

The latest version of the paper has section 8 which is a Scheme primer.

We’re planning to break that off into a separate document, because it has a much broader audience…

3

I actually think the blog example should be an entirely separate document. It’s a wonderful illustration of many important capability patterns in operation, but it seems significantly more detailed than the rest of the document. Having HoS focus on a higher-level explanation of the key ideas and concepts would likely mean writing a more explanation-level treatment of these patterns, more coherent with the rest of the document.

1 Like