Allow OCM Locking

[kobergj]

Allows locking via ocm

[micbar]

From the WOPI test suite POV, we also need GetLock and RefreshLock.

See https://github.com/owncloud/ocis/blob/master/services/collaboration/pkg/connector/fileconnector.go#L50

[glpatcern]

Interesting feature, do I understand it correctly that you want to allow Bob at remote site B to use an application deployed at his site B over files located at site A and OCM-shared by Alice@A to Bob?

In the assumption that the same application is also available at site A, how is that different from allowing Bob to use the remote (for him) application deployed at site A over files located at A and OCM-shared by Alice@A to Bob?

And in the case the same application is not available (but others may be available), can both A and B see if a lock was taken by each other? or how conflicts are to be resolved?

[kobergj]

Interesting feature, do I understand it correctly that you want to allow Bob at remote site B to use an application deployed at his site B over files located at site A and OCM-shared by Alice@A to Bob?

Yes exactly. Bob is supposed to use his weboffice (whatever that is) to edit files on another instance.

In the assumption that the same application is also available at site A, how is that different from allowing Bob to use the remote (for him) application deployed at site A over files located at A and OCM-shared by Alice@A to Bob?

From a user perspective there is probably no difference assuming the same application in the same version is deployed. Technically both approaches have their pros and cons. We decided for this one because it was the cleanest with the least effort.

And in the case the same application is not available (but others may be available), can both A and B see if a lock was taken by each other? or how conflicts are to be resolved?

When Bob opens the file in his application, the file will be locked on Alice side. This means Alice can open the same file in her application only in view-only mode.

[glpatcern]

From a user perspective there is probably no difference assuming the same application in the same version is deployed. Technically both approaches have their pros and cons. We decided for this one because it was the cleanest with the least effort.

And in the case the same application is not available (but others may be available), can both A and B see if a lock was taken by each other? or how conflicts are to be resolved?

When Bob opens the file in his application, the file will be locked on Alice side. This means Alice can open the same file in her application only in view-only mode.

Thanks! IMHO a significant disadvantage of this approach is that Alice and Bob cannot collaborate, whereas if both use the app locally deployed at A they would be able to co-edit the file. This is what we demonstrated as part of "the ScienceMesh" with apps sharing over OCM last year, and technically it didn't require a major effort: the site B offers an "Open remotely" option to Bob, which redirects him to a URL hosted by A (and shared as part of the OCM payload).

Did you consider that - and discarded for other reasons?

One aspect that was not fully addressed in our demonstration is security, but OCM 1.2 does address it in full, also in this scenario.

[kobergj]

Did you consider that - and discarded for other reasons?

Yes. But we had some problems implementing this scenario. That was also partly because of a very specific infrastructure. We had a hard deadline too, so we could not explore that option further unfortunately.

[glpatcern]

Yes. But we had some problems implementing this scenario. That was also partly because of a very specific infrastructure. We had a hard deadline too, so we could not explore that option further unfortunately.

Understood, thanks. Would be good to know more about what problems you encountered (offline if you prefer), given that we plan to implement the OCM 1.2 security level in Reva keeping the "collaborative scenario".