When loading a configuration object, what should the request include?

[ljnelson]

(See also #119.)

Given the following loading pseudocode sketch:

// Obviously sketchy provisional pseudocode
SomeLoaderResponse r = SomeConfigLoaderThing.load(...some kind of addressing...);

…what sorts of things should go in the ...some kind of addressing... area above?

For this discussion I don't care how they are represented yet (one object, many, names of classes, etc.—don't care about any of that yet).

I also don't care whether they are explicitly supplied by the user, or implicitly supplied by something else. I am just interested in the sorts of things that together make up the loading request.

Here are some things I thought of immediately:

• A type or type token. Tells the system what kind of thing you're loading.
  • (Obvious open question: if I ask for a MyConfigObject.class, would a MyConfigObject-subtyped response payload be appropriate?)
  • (If I ask for MyConfigObject<Map<String, List<Integer>>>, is that sensible? If so, what are the matching semantics?)
  • (You could see "type" as just another qualifier, i.e. type=com.foobar.MyConfigObject; see below, but it "feels" more primal than that.)
• Qualifiers, i.e. name/value pairs and such further describing what I'm asking for
  • (Maybe the application is running in the test environment and so either implicitly or explicitly the loading request should say: "Give me a MyConfigObject.class-typed object appropriate for env=test"; env=test here would be an example of a qualifier. Again I don't (yet) care if it is supplied explicitly or implicitly.)
  • (The most obvious kind of qualifier is a name, i.e. "Give me a MyConfigObject.class-typed object suitable for the name foo". name=foo is just another qualifier example.)
• Application coordinates. (Really just more qualifiers.) These name/value pairs say "where" the application "is" in "space". (Again, not interested yet in whether these are explicit or implicit.)
  • Maybe the application is running in the test environment, in a particular region, with particular feature flags.
  • Maybe the application is running in debug mode
  • Maybe the application is emulating being in a certain locale
  • Maybe the application has no real coordinates at all so "defaultish" things should be returned

Any others?

[dmlloyd]

Since CDI in its most basic form will inject by type, I think that a single type token is the appropriate answer (at least for MVP if not for 1.0).

• (Obvious open question: if I ask for a MyConfigObject.class, would a MyConfigObject-subtyped response payload be appropriate?)

Yes, this follows well-established Java idioms. Furthermore, if the type token is an interface as we have been discussing, then the response must be a subtype.

• (If I ask for MyConfigObject<Map<String, List<Integer>>>, is that sensible? If so, what are the matching semantics?)

No, at least not at present. This creates a considerable amount of complexity which we should not take on at the MVP stage.

• Qualifiers, i.e. name/value pairs and such further describing what I'm asking for

Not for MVP, in my opinion.

• Application coordinates. (Really just more qualifiers.) These name/value pairs say "where" the application "is" in "space". (Again, not interested yet in whether these are explicit or implicit.)

  • Maybe the application is running in the test environment, in a particular region, with particular feature flags.
  • Maybe the application is running in debug mode
  • Maybe the application is emulating being in a certain locale
  • Maybe the application has no real coordinates at all so "defaultish" things should be returned

These use cases are interesting, but let's put them on the back burner for MVP.

[ljnelson]

Regarding subtyping: what I meant was, suppose a user has, on the classpath:

public interface MyConfigObject {}
public interface MySpecialConfigObject extends MyConfigObject {}

Should a request for MyConfigObject.class match only the first?

[dmlloyd]

Ah, I see. Yes, it should match only the first IMO.

[dmlloyd]

Do I understand correctly that basically you are advocating for:

final ConfigObject c = loader.load(ConfigObject.class);

…to start ...

Right. We can add more variants later if use cases materialize for them.

[ljnelson]

So you agree that we cannot, now, accurately predict the number or type of potential “request” attributes? I tend to agree and think therefore they should be grouped “into” a request object, thus locating request evolution where it belongs. Thanks for your comments.

[dmlloyd]

The advantage of defining an evolving specification is that we can always add more to it later on. I'd stick with a single method accepting only a type token; we can always add overloads in future revisions if a more general request object seems indicated.