Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose more file metadata about disk-backed content #98

Closed
bollwyvl opened this issue Jul 21, 2020 · 0 comments · Fixed by #99
Closed

Expose more file metadata about disk-backed content #98

bollwyvl opened this issue Jul 21, 2020 · 0 comments · Fixed by #99

Comments

@bollwyvl
Copy link
Contributor

As some new UI work for workspaces and settings is in-flight, it would be nice to offer some additional information about stuff stored on disk. The only thing that really jumps out at me (without adding a bunch of stuff like history/rollback), is the file-system level information, namely modified and created time. This would enable the UI to answer use cases like "find the settings i most recently changed " or "find the workspace I was working on last Tuesday"

It looks like a workspace already has a metadata field (id lives there), so adding a last_modified and created would be reasonable, presumably as ISO 8061 dates.

{"values: [{
  "data": {...},
  "metadata": {
    "id": "/lab",
    "created": "2020-07-21T00:19:20+0000",
    "last_modified": "2020-07-21T00:20:20+0000"
  }   
}]}

I guess these would be overwritten on import/export, with the on-disk time always winning.

The settings API response looks a little more complicated, and perhaps these could just be added to the top level of each member of the settings array.

{
  "settings": [{
    "id": "@foo/bar",
    "raw": "...",
    "settings": {...},
    "schema": {...},
    "version": "0.1.0",
    "created": "2020-07-21T00:19:20+0000",
    "last_modified": "2020-07-21T00:20:20+0000"
  }]
}

... or metadata could be added, with these in it, and eventually extended... though the buck has to stop somewhere, and I don't imagine much but sadness if settings carried anything not validated by the schema, or how it would get populated... HTTP headers?

Of course, open to any other suggestions of what might be hidden in there that would help folks navigate this stuff!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant