As I've been working on simplifying the resolution / dereferencing language, I have found myself using the term "resolving client" as an alternative to "dereferencer" as it felt more natural.
Given that "dereferencer" is a relatively unused term, "resolving client" feels like more common English usage that has the same meaning.
This is even more apt if we remove the https binding for dereferencing as suggested in #306. If we use the term "resolving client" and when we discuss the algorithm that client goes through to
- prepare for resolution,
- call resolve on a resolver,
- process the result.
And in that discussion, the lack of an API for dereferencing makes more sense and matches more closely to the pattern we have for URLs in browsers. The dereferencer of an HTTP URL is an http client, typically a browser although server applications and command-line tools can also act as clients. HOWEVER, in those cases, it is understood that when talking about the browser as an http client, we are focusing on its role in HTTP (pre, exec, and post) and not concerned with other functionality, even when that functionality is common expectation. For example, browsers expose a variety of APIs through a variety of interfaces. When discussing a browser as an HTTP client, however, those APIs need not be discussed.
Overall this seems like a helpful simplification, getting rid of a new and confusing term without losing needed specificity.
Thoughts?
As I've been working on simplifying the resolution / dereferencing language, I have found myself using the term "resolving client" as an alternative to "dereferencer" as it felt more natural.
Given that "dereferencer" is a relatively unused term, "resolving client" feels like more common English usage that has the same meaning.
This is even more apt if we remove the https binding for dereferencing as suggested in #306. If we use the term "resolving client" and when we discuss the algorithm that client goes through to
And in that discussion, the lack of an API for dereferencing makes more sense and matches more closely to the pattern we have for URLs in browsers. The dereferencer of an HTTP URL is an http client, typically a browser although server applications and command-line tools can also act as clients. HOWEVER, in those cases, it is understood that when talking about the browser as an http client, we are focusing on its role in HTTP (pre, exec, and post) and not concerned with other functionality, even when that functionality is common expectation. For example, browsers expose a variety of APIs through a variety of interfaces. When discussing a browser as an HTTP client, however, those APIs need not be discussed.
Overall this seems like a helpful simplification, getting rid of a new and confusing term without losing needed specificity.
Thoughts?