create new share: name vs opaque resource id about ocm-api

[dvh]

The name field is meant for convencience only and is a human readable name of the document (just like description). I think the resourceId is part of the actual resource which is located in the protocol object.

[schiessle]

In reality “name” should be a unique identifier of the resource in the scope of owner and providerid. It should not be a filename or path as such (although it could be if unique).

For whom should it be unique? We could only guarantee uniqueness for the sender, not for the recipient. Also to ensure uniqueness for the sender we would need to track the "names" we already send before to make sure to generate unique names for the new shares. This results in additional overhead and at the moment I don't see the benefits.

With respect to the "old" API, the name was considered to be the name of the resource (file or folder). I think it also makes a lot of sense to send the name directly with the share request. Otherwise you would need to ask the sender again for the resource name. In case of webdav this could be a propfind, if we want to support other file transfer mechanism in the feature we don't know if and how this will be possible. In any case it would add a lot of extra work to the programmer who implements our API to implement a "retrieve resource name" for any possible file transfer mechanism, we would have additional overhead (an additional request) and the risk that a future file transfer mechanism doesn't know the concept of a (useful) resource name but only transfers the payload. Therefore at the moment I think sending the name of the resource directly with the share request makes a lot of sense.

[labkode]

For whom should it be unique? We could only guarantee uniqueness for the sender, not for the recipient. Also to ensure uniqueness for the sender we would need to track the "names" we already send before to make sure to generate unique names for the new shares. This results in additional overhead and at the moment I don't see the benefits.

This problem arises in your implementation, your implementation needs to check for unique file target names, resulting in a O(n) complexity. Our implementation is O(1) as we do not require to consult previous state to create a unique file target names for the recipient namespace.

With respect to the "old" API, the name was considered to be the name of the resource (file or folder). I think it also makes a lot of sense to send the name directly with the share request. Otherwise you would need to ask the sender again for the resource name. In case of webdav this could be a propfind, if we want to support other file transfer mechanism in the feature we don't know if and how this will be possible. In any case it would add a lot of extra work to the programmer who implements our API to implement a "retrieve resource name" for any possible file transfer mechanism, we would have additional overhead (an additional request) and the risk that a future file transfer mechanism doesn't know the concept of a (useful) resource name but only transfers the payload. Therefore at the moment I think sending the name of the resource directly with the share request makes a lot of sense.

The solution @moscicki proposed is to have a new field called basename for the "name of the resource" and still have a resourceid that uniquely identifies the share object.
Another solution is to encode both in the name field: fileid=1234,name=/My Share but I think is cleaner the previous solution.

[dvh]

I don't really understand the problem. I think the implementer should use it's own identifier(s).