create new share: name vs opaque resource id

[moscicki]

POST /shares

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). But it could be an opaque fileid for example. For that purpose I would maybe call it resourceid.

If we accept the idea that resourceid string may not be interpretable by receiving end, the question arises if a name of the resource (basename) should not be provided in addition.

[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).

[michielbdejong]

Some receiving servers will use the name to add the resource to the recipient's collection, and then you may end up with things like 'hello (1).txt' but this is quite a common pattern that also happens in operating systems like MacOS and Windows, and in for instance Dropbox.

For referring to the share in for instance follow-up notifications, providerId is already in use.
For accessing the API, for retrieving the resource, as @schiessle said, this is protocol-specific (e.g. identifier of the video call you are invited to join, that is probably a number or string and doesn't have a file path) so we should not prescribe anything for that at the OCM level.

Philosophically, there is also "the resource itself" which is separate from the share that shares it and from the URL or ID that allows the receiver to access it, but I think if the OCM protocol can establish unique share ids, and the resource access protocol can establish unique resource access ids, then we have all interactions covered, and don't need to model anything beyond that, and don't need to add any opaque strings beyond the existing providerId.

So let's keep name as a human-readable (not opaque and not guaranteed to be unique), for display in user-facing notifications, and as a suggestion to base a unique local identifier on (for instance if a shared folder becomes a mounted folder in the recipient's EFSS file system view, as is quite common).

It looks like this was a discussion from 7 years ago that has at the time led to the rough consensus that I think we have about this issue nowadays. Closing.