Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do we want to support more than one protocol at a time? #66

Closed
glpatcern opened this issue Mar 14, 2023 · 7 comments · Fixed by #69
Closed

Do we want to support more than one protocol at a time? #66

glpatcern opened this issue Mar 14, 2023 · 7 comments · Fixed by #69

Comments

@glpatcern
Copy link
Member

This discussion started on another issue, but it is important to settle on it.

Following #54 and #57, we have introduced the option to specify more than a protocol in a share action.

The rationale of this is to enable richer use-cases such as what I demonstrated at CS3 Barcelona, where the user could access the data (via webdav) and the remote application at the same time (via webapp), or what @schiessle came up with as another example: imagine you share a calendar event, and you want the recipient to access the event data via CalDAV (i.e. protocol = webdav), as well as connecting to some groupware tool such as Zoom, Nextcloud talk, etc. (i.e. protocol = webapp).

From @smesterheide:

I think the original definition was superior to having different protocols defined as properties. Can we use name as a discriminator?

The original definition was just an object, which does not offer any clue as of how implementations are supposed to encode the properties. No surprise that compatibility across different vendors was not ideal (e.g. only recently did Seafile announce compatibility with Nextcloud).

Using just a single property - the shareType rather than the name I guess - as discriminator implies that there's a single "dimension" to express all options. This has two issues:

  1. We'd need to come up with counterintuitive labels to represent the whole shareType x protocol matrix: for the above examples, something like file-webdav, file-app, caldav, calendar-talk-app?
  2. Even worse, a user that wants to share a file with two protocols / access methods at the same time, would need to create two independent shares, with poor UX (why would I need to share twice?) and inconsistent scenarios thereafter - what if one of the two shares is later removed? does the recipient keep the permissions on the other one? either way it's wrong/inconsistent.

More opinions welcome!

@michielbdejong
Copy link
Contributor

michielbdejong commented Mar 14, 2023

I think "need" is a strong word. It implies break the entire eco-system of already deployed servers.

For comparison: Is IPv6 better than IPv4? I think yes. But do we "need" IPv6? I think no.

But to move forward on this issue:

I think we can use graceful degradation here, and make it a discoverable feature, maybe? So by default all servers need to implement single-protocol OCM (both when sending and when receiving), but if the sender supports it, and the receiver advertises support for it, then multi-protocol can also be used, and this opens up new user stories. If these user stories prove to be interesting enough, then implementers will all add support for it and it can be rolled out gradually across the existing eco-system, as a new useful (but in the basis still optional) feature.

@glpatcern glpatcern changed the title Do we need more than one protocol at a time? Do we want to support more than one protocol at a time? Mar 14, 2023
@glpatcern
Copy link
Member Author

OK, let's get the phrasing correct :-)

My point was more on trying not to bend the current spec beyond reason. I'm happy to discuss how to implement any sort of interoperation (with graceful degradation in mind), provided that we are not forced to stretch the meaning of the shareType property.

@glpatcern
Copy link
Member Author

Very practically speaking:

  • we could go back to a protocol property, which in v2 is actually an array. If both sender's and receiver's sites advertise multiple protocols at its /ocm-provider endpoint, then they can assume a multi-protocol share is supported, otherwise they shall assume that only one protocol is supported (being it webdav, but without being said).
  • also the shareId property can be renamed back to providerId, keeping the description so that we know what we're talking about

@smesterheide
Copy link
Contributor

Given the fact that an actual use case with working code exists for multiple protocols per share, we should be practical and support this in the most simple way possible.

Generally speaking I think we can still fail (or fail gracefully) if a certain share tuple (resourceType, shareType, protocol) is not supported without providing the full caps beforehand. Is that what you have in mind @michielbdejong?

To provide some reference I will attach screenshots for the /shares endpoint that contrasts the original definition with the current develop branch. I think we can discuss the discovery endpoint separately here: #51, #59

20230320_new_share_develop
develop

20230320_new_share_v1 0 0
v1.0.0

@michielbdejong
Copy link
Contributor

Sorry, what I meant with "graceful degradation" is that we should keep compatibility with existing systems at all times, in the same way that many websites can still be browsed with a text-only browser and no JavaScript.

So as per #66 (comment)
I think we should change it back to protocol and providerId. That way all servers are compatible for basic single-protocol sharing. In the comments we can explain what the term providerId means, and it will be fine.

And then if the sender knows that the receiver supports multi-protocol shares, it can send a share that has protocols as an array instead of protocol as a single object.

@glpatcern
Copy link
Member Author

glpatcern commented Mar 20, 2023

I agree on the general idea. Now a nuance to be agreed upon is the following: in v1.0.0 one expects a payload with a protocol.name (string), together with an unspecified protocol.options object. In the current development branch (assuming to use protocol as opposed to protocols) we'd have instead e.g. a protocol[webdav] as a (fully specified) object, and possibly a protocol[webapp], etc.

To save backwards compatibility to some extent, even if the old spec leaves the protocol.options completely unspecified (thus it's fine IMHO to drop it in v2), we need to keep a protocol.name. I have some ideas - what if we discuss over video chat?

@michielbdejong
Copy link
Contributor

Yes! I'm a bit busy with another project this week, but maybe we can have a video chat on Wednesday?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants