-
Notifications
You must be signed in to change notification settings - Fork 12
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
Comments
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. |
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 |
Very practically speaking:
|
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 |
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) And then if the sender knows that the receiver supports multi-protocol shares, it can send a share that has |
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 To save backwards compatibility to some extent, even if the old spec leaves the |
Yes! I'm a bit busy with another project this week, but maybe we can have a video chat on Wednesday? |
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 (viawebapp
), 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:
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:shareType
xprotocol
matrix: for the above examples, something likefile-webdav
,file-app
,caldav
,calendar-talk-app
?More opinions welcome!
The text was updated successfully, but these errors were encountered: