Versioning, history, find commits from resource

[atomicdata-dev]

Versioning, history, find commits from resource

[joepio]

Flow for discovering versions from the browser

Let's assume we look at some resource, and want to see the previous version. How do we get there?

• Extend resource. Start with the Resource. the get_extended_resource functions adds Add a property to every resource which links to it's versions, e.g. /versioning?resource=subject.
• Extend view. The HTML template creates a URL when rendering the page. This means that it is not discoverable through the data itself.

What does this endpoint return

• A Collection of links to dynamic resources, namely versions, like /versioning?version=commitUrl. This is created by doing two TPF queries,

How does the library construct a version

• User fetches that URL, server asks the store a TPF query for all Commits for that resource. User can select any version. On opening that version, it is constructed.

[joepio]

I was considering using get_resource_extended for constructing a Versioned item. This basically enables atomic_lib users to simply user URL strings as the API, instead of relying on a Server.

This brings me to another consideration. Who should calculate the Version? A /version?commit={} URL can be resolved, as long as the Commit itself is resolvable (which is the case for HTTP or IPFS urls). Currently, I use a TPF query on a local store to find all commits.

Made a new issue about this more abstract problem: #89

[joepio]

Endpoint design

Should there be one endpoint for looking at one specific /version and a collection of /versions for one commit?

Say we have one versioning endpoint. Depending on the query param set, it will return either a Collection of versions, or a single resource. Having wildly different types of one resource from one endpoint feels odd, and I haven't even discussed the awkwardness of dealing with multiple query parameters. So this seems like a bad idea. Yeah, we need two endpoints.

If you open the versions endpoint without passing any query parameters, what should be returned?

• As a browser visitor, I want to see a page that explains the endpoint, and offers a simple way of using the endpoint, ideally through a webform.
• As an API user / machine, I might want to render my own custom form

Hmm. I think it might be possible to define an abstract endpoint class, which has a generic view. Basically this: atomicdata-dev/atomic-data-docs#15

[joepio]

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 atomicdata.dev.

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.

[joepio]

The Versioning endpoints

Where are they going to live?

Custom Actix handler in atomic-server

Add an actix handler. Manually parse incoming query parameters. Generate a Resource depending on the request.

• Existing actix features could be useful

Custom Handler in atomic-lib

Get's called by get_extended_resource through existing match statement, similar to how Collections work - except for that now it also checks paths!

• More flexibility
• Moves routing to atomic

Add Endpoint resources in the default store

• Everything lives in data, which means more extendability if done right
• Not sure if this is actually going to work

Add 'register_endpoint' feature in store or server?

[joepio]

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

[joepio]

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 extenders

In the get_resource_extended method, we could iterate over a bunch of registered extenders, which add properties to resources. Seems like a powerful abstraction.
Prevents that the button is shown when versioning is not possible.

Add components in the front-end.

Is easy to do, but this will result in buttons for things that have no versions (such as collections).

[joepio]

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