Skip to content
This repository has been archived by the owner on Mar 7, 2024. It is now read-only.

Support for re-reading files #12

Open
lasselindqvistsolibri opened this issue Apr 6, 2021 · 5 comments
Open

Support for re-reading files #12

lasselindqvistsolibri opened this issue Apr 6, 2021 · 5 comments

Comments

@lasselindqvistsolibri
Copy link

The API does allow user to choose a file via a web browser basically and then the application to read the contents of that file.

But does this API support the application to keep a unique identifier of that file, and later use that identifier to query the status/version of it from the server? The application would then see if the version has changed indicating changes in it and re-read the contents of the file. This would allow the application to automatically update the local contents from a server file.

@jsdbroughton
Copy link

Should this be as a SHA hash or something more human readable?

@lasselindqvistsolibri
Copy link
Author

Should this be as a SHA hash or something more human readable?

I would personally prefer something with an order, if possible. Dropbox has revision in their API that tells how many changes there have been. Microsoft has at least timestamps in their Graph API.

@GeorgDangl
Copy link
Member

Would a simple string identifier, generated by the server, work? Then the client has a unique key for the file, and the server may decide how this key looks.

@ykulbak
Copy link
Collaborator

ykulbak commented Apr 11, 2021

The API provides permalinks to list the revisions of the file and get its metadata. Once an application has obtained the URLs for these endpoints it should be able to use those to refresh the information about the file.

@lasselindqvistsolibri
Copy link
Author

The API provides permalinks to list the revisions of the file and get its metadata. Once an application has obtained the URLs for these endpoints it should be able to use those to refresh the information about the file.

Do you mean the vendor-specific metadata? If so, that cannot be used in an application without beforehand-knowledge to implement automatic reloading of file contents. It would require a vendor-specific solution for each possible vendor.

But if it is the VersionsLink https://github.com/buildingSMART/OpenCDE-API/blob/master/openapi/openCDE-spec.yaml#L152
and if / is guaranteed to return static version strings that neven change, it would be usable for this purpose.

Related note:
https://github.com/buildingSMART/OpenCDE-API/blob/master/openapi/openCDE-spec.yaml#L191
uses "revisions" in the URL? Is this an accident and it should be "versions" or is revision a different thing?

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

No branches or pull requests

4 participants