kcp
kcp copied to clipboard
kcp-dev
Replace "virtual workspace" terminology with "view" everywhere
| Old | New |
|---|---|
| virtual workspace | service |
| APIExport virtual workspace | APIExport service |
| Syncer virtual workspace | Syncer service |
| Workspaces virtual workspace | Workspaces service |
| Initializing workspaces virtual workspace | Initializing workspaces service |
| pkg/virtual | pkg/service |
| cmd/virtual-workspaces | cmd/kcp-services (?) |
| docs/virtual-workspaces.md | docs/services.md |
- global search for "virtual workspace" and addressing results as needed
Some of these make me wonder if we'll be muddying up the term service. A service, in my head, encapsulates the entirety of:
- The exposed API
- The virtual workspace view
- The implementation that fulfils requests
- Maybe other things specific to how I implement my service
But I like where this is going. Is there value in keeping the workspace concept in there? Like virtual workspace -> service workspace. Or maybe that confuses the place the service is deployed too, so maybe virtual workspace -> service api workspace.
@pweil- we need to remove "workspace" from this term - these "things" are not workspaces 😄
If I understand correctly, the concept here is very analogous to what, in the database community, is called a "view". I think we should focus on that term, it will readily lead the reader in the right direction.
If I understand correctly, there is one more critical specific feature of the concept here, which is that a virtual workspace looks the same, to a client, as a plain Kube cluster or a kcp workspace. That is, it provides what I call a "kube API service".
So I suggest the following possibilities.
- view API service
- view service
- API service view
- service view
I prefer the first two because I think they are less restrictive in semantics. The latter two suggest that one of these is a view of one API sservice, and I think that cardinality restriction is not something we desire here.
Yep, we had brandied around the "view" terminology early on as well.
I like view as that doesn't conflict with the core v1 Service API type. Would also rework /services to /views in the URLs.
@sttts @davidfestal @stevekuznetsov let's nail this down - would you prefer service or view? (or <shudder> do you want to suggest something else?)
This is what the table looks like for views:
| Old | New |
|---|---|
| virtual workspace | view |
| APIExport virtual workspace | APIExport view |
| Syncer virtual workspace | Syncer view |
| Initializing workspaces virtual workspace | Initializing workspaces view |
| pkg/virtual | pkg/view (or pkg/views) |
| cmd/virtual-workspaces | cmd/kcp-views |
| docs/virtual-workspaces.md | docs/views.md |
Proposal: blast this out to the mailing list, give a spot at the next community call to speak or forever hold the peace, and then change it over next week.
Issues go stale after 90d of inactivity.
After a furter 30 days, they will turn rotten.
Mark the issue as fresh with /remove-lifecycle stale.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
@kcp-ci-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten./close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.