-
Notifications
You must be signed in to change notification settings - Fork 42
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
Versioning, history, find commits from resource #42
Comments
Flow for discovering versions from the browserLet's assume we look at some resource, and want to see the previous version. How do we get there?
What does this endpoint return
How does the library construct a version
|
I was considering using This brings me to another consideration. Who should calculate the Version? A Made a new issue about this more abstract problem: #89 |
Endpoint designShould there be one endpoint for looking at one specific Say we have one If you open the
Hmm. I think it might be possible to define an abstract |
I've got the first test passing (yay!), but it's incredibly slow. That's because I create a new store where the new Resources are to be made, and that means that all props first have to be fetched. And that is done by retrieving all the needed props from A different approach may be to use the normal store, and to temporarily remove the existing resource, and set it back after creating the older version. |
The Versioning endpointsWhere are they going to live? Custom Actix handler in atomic-serverAdd an actix handler. Manually parse incoming query parameters. Generate a Resource depending on the request.
Custom Handler in atomic-libGet's called by
Add Endpoint resources in the default store
Add 'register_endpoint' feature in store or server? |
I've opted for creating an Endpoints abstraction, which seems like a decent abstraction for extending functionality of an Atomic Server. See atomicdata-dev/atomic-data-docs#15 |
Things are working! But I still have a problem to solve: showing the 'versions' button in a resource. There's a couple of approaches to: Add an action link to all (versionable) resources, register
|
I think this has been working for quite a while now. Also, this helps to find commits, and removes the need for a different endpoint: #172 |
One of the advantages of using and storing Commits, is that we have a full history of every single resource. However, we currently have no way of browsing this information.
Wishes
Considerations
Approaches
Versions endpoint
example.com/versions?subject=someresource
lists all the version for the resource included in the Subject query parameter. It returns a collection. Perhaps first define the Endpoints feature?example.com/versions?subject=someresource&version=signatureHashBlablabla
)Introduce sequential TPF queries
Knowing which commits are linked to a resource, can be done using two TPF queries:
is-a = commit
subject = mySubject
Some time ago, the great Ruben Verborgh told me that you can actually convert (all?) SPARQL queries into a set of sequential TPF queries. That's pretty cool. How should we create an interface to facilitate this? It probably requires some form of nesting queries, and some form of combined queries.
But... this kind of discussion quickly turns into a difficult discussion of which methods need to be included in the newly designed query language, and will kind of lead to some almost-turing-complete language, but not fully. Therefore, we might want to try a plugin-like approach, where the query logic resides in code.
Plugin (endpoint + extend resources)
Atomic Plugins are currently just a bunch of thoughts, but perhaps
Versions
is a logical first plugin. Plugins should be apps that can be added to an Atomic Server at runtime. They might be run using a WASM runtime. In any case, they need to add functionality to an Atomic Server.Ideally, the Versioning plugin will have:
Constructing a version
A Version is a representation of some Resource at some point in time. Constructing one can (theoretically be done in several ways:
I feel like the first approach is the most logical.
I have a problem with this, though. Some resources don't have commits: for example, resources that are imported from a static AD3 file (such as the default atomic data).
I think this should simply be handled by the plugin. If you try to construct a version for a resource that has no commits, just return an error. Or should it return the static version that?
The text was updated successfully, but these errors were encountered: