Splash

Unsolved Design Issues

Obsolete

Malicious code can't access other data, but can waste system resources
Some kind of capability to a bucket of memory that needs to be passed in to object creation
- Where would this come from in the general case? The session? How would it be determined how much to give?
Unsolved problem in capability literature

Purpose of filesystem in existing systems: Give system-wide names for resources that do not change as the data is changed or replaced
- Splash (by design) is missing this abstraction
- What good uses are there for a filesystem and how could they be integrated with Splash?
Object groups - FS-like tree of important objects that could each have several sub-objects
- Probably only useful for system objects
- Difficult to integrate with capability model - how do you reference a specific object in the tree by path directly
How to back up or transfer objects?
- Copying an object would result in a new ID- not the same as original object
- Does the storage manager need to have the ability to keep track of multiple copies of an object?
- How does the storage system handle removable media at all?!?!
- "Filing in/out" like smalltalk?
Versioning Components?
- Is versioning something that should be built in? Or something written on top of mutable objects?
Immutable objects
- Hash of data is key- makes life easier
- How would it be created? - Mutation is necessary in creation phase
Mapping of objects to storages - how could this be determined?
Object.become like smalltalk?
- Bad idea- violates lots of invariants with optimization

Untrusted code could hold a capability back to an object owned by its creator and use it to pass data about the user: How to prevent spying?
- Code must have limited access to other objects even if a capability is presented! - How do we know when to allow or deny?