Create glossaries for general terminology and to name the components. #17
Conversation
| paths | ||
| Subpath within the final presented content of a deconst site. Includes the fully-qualified | ||
| domain name of the page. For example: | ||
| ``developer.rackspace.com/sdks/cloud-servers/getting-started/``. |
There was a problem hiding this comment.
I'm abusing the word "path" here a little, since we have to include the domain as well. We could call them "presentation IDs" or something instead, but that seems silly.
There was a problem hiding this comment.
I'm a bit confused, is the path just /sdks/cloud-servers/gettingstarted or must it include the domain?
There was a problem hiding this comment.
Because we need to support multiple domains, we need to include the domain. It needs to be unique across the deconst-managed web presence, so that we can map it unambiguously.
I realize this doesn't really make it a "path" any more, but I couldn't think of what a better name should be, without being so generic as to be meaningless.
| ``https://github.com/deconst/deconst-docs/tree/glossary/running/architecture``. | ||
| * A specific post in a Jekyll blog, generated from (theoretical) content at | ||
| ``https://github.com/rackerlabs/developer-blog/_posts/mongodb-3.0-getting-started.md``: | ||
| ``https://github.com/rackerlabs/developer-blog/blog/mongodb-3.0-getting-started``. |
There was a problem hiding this comment.
@kenperkins Is this any better? I'm struggling trying to communicate this one for some reason.
|
That looks a bit more explicit. 👍 |
|
Okay, great. Finding a more appropriate name for "path" is the only concern left, then. |
|
@kenperkins, @rgbkrk, @steveortiz: I've added a diagram for our initial architecture, including only components that we should work on for the first milestone. Let me know what you think, have giant flame-wars amongst yourselves, etc. |
|
lgtm. |
|
Nice diagram. |
|
Concurrence: reached 🏁 |
Create glossaries for general terminology and to name the components.
It's confusing to be using different words for the same things. Let's agree on a common lexicon.
This is my proposal for what we should call various things. If you disagree, please comment on the request so we can agree on better names! Once I click that tempting green merge button, anyone who talks about the "renderer" or the "pipeline" has to buy me a coke.
I've also taken a stab at assigning responsibilities to different parts of the system based on my current understanding of what we're trying to build. I've left some things intentionally vague, like where layouts are managed, because I don't have a clear vision yet of where that should be done (:point_right: to #6 if you have thoughts to contribute there specifically). If I'm wildly off about any of the things I did nail down, this would also be a good place to talk about that.
/cc @rgbkrk @kenperkins @steveortiz