Browse Source

Correct notes with a rather obvious observation.

Benjamin Shelton 1 year ago
1 changed files with 5 additions and 3 deletions
  1. +5

+ 5
- 3 View File

@ -12,9 +12,11 @@ During the KeyStar client initialization--the primary entry point for most use c
* The current API is likely going to be changed such that the KeyStar instance only returns points to a KeySpace. Originally, I had intended to make secrets and namespaces available via KeyStar, but I'm beginning to think this is impractical. Tying secret access into the KeyStar instance would create too many layers of indirection and interfer with a clearer execution path. Part of the intent with this rewrite is to make clear some facets of the application and include extra features (authentication) that were missing in the previous implementation.
* Likewise, namespaces may or may not be selectable from the KeyStar instance. Partially, this is because there will be no way to determine which KeySpace contains the requested namespace unambiguously. If we implement multiple key spaces (and their backends) as an option per-KeyStar instance, this further complicates direct access for a given namespace. At best, we might provide a means for extricating a key space based on its connection string, or an identifying hash of the connection string, or will allow callers to attach a symbolic name with the key space.
> Not sure if this would work
> Not sure if this would work (it should; just tested; requires import _ for side effects)
> examine database/sql for evidence if you don't believe me or:
> Use build tags in files that import other packages
> packages have build tags + Init() functions
> packages have build tags + init() functions
> e.g.:
> fs_loader.go: +build filesystem
> fs package: func Init().go
> fs package: func init().go