create new share: indicate resource type

[moscicki]

POST /shares

Shouldn't we possibly include a type of the shared resource so the receiver may interpret correctly what is shared? Which should or could be enumerated value in the set “file”, “folder”.

[dvh]

I agree. But, in the case of a file, would you also like to know what kind of file it is? E.g. the mime-type of the file to be able to show an Excel logo if it's an Excel file?

[schiessle]

I agree that a share type would make a lot of sense

Which should or could be enumerated value in the set “file”, “folder”.

At Nextcloud we want to extend federated sharing beyond files in the future, e.g sharing a address book, a calendar, etc. So a type would be really useful and I wouldn't limit it to "file" and "folder". The server then can just reject share types it doesn't know.

[dvh]

So we should introduce a non-enumerated filetype field?

[tomneedham]

At a minimum we should introduce this field, with at least the possibility for file and folder. The problem with accepting other values is will we then end up with a fragmented set of share options for each of the types between vendors?

[schiessle]

At a minimum we should introduce this field, with at least the possibility for file and folder.

In good Unix tradition just 'file' might be enough. In order to know how to handle the share a distinction between files and folder might not be necessary. As for other share types I would follow the XMPP example and allow extensions to the standard. For example if we at Nextcloud implement calendar sharing we will provide a definition of the share type "calendar". We can then discuss it, agree on it in order to make it a "official" extension and improve/enhance it if necessary. All extensions will be optional. If a solution receives a share with a share type it doesn't know/implements it just returns 501 and done.

But I would suggest to hold this discussion a little bit back for now. We at Nextcloud making good progress implementing OCM and will soon come back to you with some suggestions based on a real world implementation so we don't have to discuss in theory but based on stuff which we know that it works.

[glpatcern]

This is effectively the case in the specs, already as of v1.0