Package Layout

[dskatz]

Since there are a few of us working on the initial tasks for the validator service, I was thinking a quick discussion on the package layout would prevent some conflicts and pain points.

My proposal is:

1. internal/config - holds main configuration loading via file / watchers
2. internal/config/parser - main logic to create the 1:1 mappings used for determining permission boundary
3. internal/server/middleware/authorization - middleware handlers for authorization
4. pkg/aws/cloudfront - integration with cloudfront apis

cc @richerve @whwalter @yuzhouliu9

[richerve]

LGTM so far

[colinhoglund]

We typically keep server handlers under ‘internal/server/‘

[whwalter]

Not sure if we want to differentiate middleware vs top level handlers via namespace.

internal/server/handlers/authorization will be a handleFunc in Interface but not meaningfully because it won't handle authorized requests.

pkg/config/parser feels like it is internal here. It will read a config and return a permissions boundry type that is also likely an internal implementation detail.

[dskatz]

Yeah, internal/server/middleware makes more sense for authorization. I was thinking that the authorization step is a middleware function that has access to the parsed config, evaluates the permission boundary and if it passes sends the request on to the next function.

I can see an argument for the config parser being internal. At the very least I think it is important to maintain a clear separation from the operations of reading and watching for config file changes and the logic that creates these internal mappings from the config file.