Support Container Versioning

[philborlin]

The spec allows for versioning of containers: http://docs.openstack.org/developer/swift/overview_object_versioning.html

Versioning would need a few additional methods on both the Container and the StoredObject

StoredObject:

1. addVersioning - Sends a X-Versions-Location header - I personally feel it would be useful to have Joss create a versioning container for you and to auto name it but this is up for debate. If this is not the case you would probably pass the container you want to use for versioning as a parameter
2. isVersioned
3. removeVersioning - Sends a X-Remove-Versions-Location header

There are a few commands for StoredObjects that go along with versioning:

1. getPreviousVersion
2. listVersions
3. deleteAllVersions - It would probably be convenient to have a delete all versions command since delete on a versioned container only deletes the most recent update.

I can issue a pull request if that would be helpful, but I would like to hear some comments before I put anything to code.

[robert-bor]

Hi Phil, thanks for the write-up! I assume your first summary of methods should be for Container, not StoredObject. My provider does not support versioning. Do you have a test account or alternatively a provider name (to get my own test account) so I can try out versioning?

I would like to rename addVersioning and removeVersioning to enableVersioning and disableVersioning. Passing the Container as an argument, both for enabling and disabling sounds most in line with the current API, though I'm definitely open for discussing the option where JOSS provides some convenience. I wonder if multiple X-Versions-Location headers can be set. If not, disabling could be inferred from the active header, saving an argument.

Your suggestions for the StoredObject methods make a lot of sense too.

[robert-bor]

My provider has notified me they will enable the Object Versioning feature soon.

[philborlin]

That is great. I wrote up a comment yesterday but it looks like I forgot to hit the comment button.

To sum up what you said in API form the Container should gain the following methods:
public void enableVersioning(Container container)
public boolean isVersioned()
public void disableVersioning()

You do not need to state the name of the versioned container when removing it.

For the StoredObjects API I am not sure whether you want to introduce a Version object or if you just want to use strings. It might be interesting for listVersions() to return a Version object that contains the StoredObject the version points to. I am also not sure if all the StoredObject methods pertain to a version but many of them still do. If the API was structured this way you would not need a getPreviousVersion method.

[robert-bor]

I think a StoredObject which is part of a versioned group, must always be capable of getting the previous or next version. A call to such a method would return another StoredObject (preferably not a String), so that you can safely call download on that one.

It might be good to have a check on whether the StoredObject is in a versions container and disallow uploads. It could be that Swift already checks for this. Unable to check that, though.

Since StoredObject and Container do not make a roundtrip to Swift until a method is called, the best option would probably be to build up version knowledge as soon as a version method (eg, getNextVersion) is called. If the container does not have versioning enabled, it can throw an exception.

So, basically:

1. as soon as a version method is called, a version object is created that knows all the versions of an object and the order among them
2. the version object will create a number of StoredObjects
3. each of this StoredObjects knows its neighbours and the generic version object (the version brain)

For good measure, I will be computer-less for the next two weeks. If you feel like giving it a try, I would love to integrate your pull request when I'm back.

[liebig]

Are there any news on this? Is versioning now supported?