Limiting Direct Access to Holons

[evomimic]

Summary

This discussion explores mediating access to Holons through HolonReferences as much as possible. The focus on this discussion is primarily on clean definition of the Reference layer and Shared Objects layer of the architecture.

Assumptions:

• Operations on Holons can be mediated by HolonReference (implementing HolonReadable)
• Nursery (a.k.a., StagingArea) is ping-ponged, staged holons can be accessed via StagedReference on both client and guest-sides
• HolonsCache is NOT ping-ponged (because access requirements are different for client and guest)
• HolonReference, SmartReference and StagedReference abstractions are portable and defined on both client and guest.

Objects Requiring Direct Access to Underlying Holon

The ONLY objects requiring direct access to Holons are:

1. StagedReference implementation needs direct access to staged Holon in order to implement HolonReadable and HolonWritable
2. SmartReference implementation needs direct access to cached Holon In order to implement HolonReadable
3. Whatever object actually implements the ping-pong for Nursery to/from StagingArea needs direct access to staged Holons
4. Client-side cache needs ability to retrieve actual Holons by HolonIds (on demand)

Traits can be used to partition functionality and avoid circular dependencies. Both traits and object definitions should reinforce the clear separation of architectural layers.

Reference Layer

An references_api module could define the following:

• HolonReadable trait -- offering read-only methods on individual HolonReferences
• HolonWritable trait -- offering mutating methods on individual HolonReferences
• StateMobility trait -- to supporting extracting Nursery state and HolonSpace HolonReference (ONLY) to ping-pong operations
• HolonStagingBehavior trait -- to stage new holons and retrieve staged holons by key
• HolonLookup trait -- to get HolonReferences to committed holons by HolonId and by key
• CollectionReadable trait -- offering read-only methods on HolonCollections
• CollectionWritable trait -- allows HolonReferences to be added and removed from HolonCollections
• HolonsContext struct -- provides access to HolonSpaceManager and dance state.

The Reference Layer is also the home for:

• HolonReference struct that implements HolonReadable
• SmartReference struct that implements HolonReadable
• StagedReference struct that implements HolonReadable and HolonWritable
• HolonCollection struct that implements CollectionReadable and CollectionWritable
• HolonSpaceManager struct that implements StateMobility, HolonStagingBehavior, and HolonLookup. The HolonSpaceManager also implements the Shared Objects Layer NurseryAccess and HolonCacheAccess traits and owns the Shared Objects Layer structs: Nursery, HolonCacheManager, and CommitService

Shared Objects Layer

An shared_objects_api module could define the following:

• NurseryAccess trait -- that offers a StagedReference access to its underlying staged Rc<RefCell>
• HolonCacheAccess trait -- that offers a SmartReference access to its underlying cached Rc<RefCell>

The shared_objects layer is also the home for:

• HolonCache struct that implements the HolonCacheAccess trait
• Nursery struct that implements the NurseryAccess trait
• CommitService struct (and associated CommitResponse struct and CommitStatus enum)

Implementation Notes:

• SmartReference invokes get_rc_holon on HolonSpaceManager (obtained from context)
• HolonSpaceManager:
  • determines proper Space from HolonId
  • delegates get_rc_holon to its Cache (if LocalId) or the HolonSpaceProxy if ExternalId
• HolonCache provides the actual implementation of get_rc_holon (this implementation already exists in HolonSpaceManager and just needs to be migrated to HolonCache).

Persistence Layer

This layer encapsulates all calls on the Storage Layer. It is the ONLY layer that is allowed to call holochain storage functions. The types exposed by this layer are HolonNode EntryType and the SmartLink LinkType. Files in this module cannot refer to types defined in the Shared Objects Layer (which depends on the Persistence Layer). This means they cannot reference Holon or HolonError.

• Remove dependency on the Holon and HolonError types from holon_service.rs.