[RFC] Caching Layer

[slogsdon]

• Application Data
• Compiled HTML
• Adapters
  • ets
  • redis
  • memcached

[slogsdon]

I see two options for this, which may or may not overlap.

Plugs

A plug-based solution where the plug is responsible for putting and deleting objects to a data store. It discovers updates to the store via an intermediate, private collection within conn.private. Controller actions must front most of the work in terms of managing the intermediate collection by modifying the connection or pass off the connection to the data layer (which would then have to know about and modify the connection).

I'm not too fond of requiring the data layer to reason about modifying connections. Seems unnecessarily cluttered.

Separate Caching Layer

A caching layer built upon a new process tree (to be supervised by the main application supervisor). The "master" pid/something would need to be tracked in order to access the rest of the (supposed) caching system. Cache interaction could occur anywhere that it is deemed necessary without intertwining separate layers of the application. As an example, the data layer would not need to know about connections with this, whether a controller action decides to interact with the cache or not.

Keeping a separate process tree from the rest of Sugar may offer the cleanest API by trading off some complexity/architecture.