Add design document for web app sharing

[mickenordin]

No description provided.

[MahdiBaghbani]

This is a good start for the M8!

[glpatcern]

I have some comments / proposed changes, maybe useful to put them here prior to merging this (even if it's "only" a working proposal)

[glpatcern]

Here are my comments, mostly food for thought and further discussion!

[glpatcern]

The intent of the current viewMode was to encode the permissions given by the app in a slightly different way than the permissions already defined e.g. in WebDAV, in particular as it includes a view_only, which Collabora Online renders as "you can't download, only preview".

I propose to keep viewMode as is, and instead introduce a new field target, similar to the <a> target in HTML, with values being iframe, redirect (or blank maybe?), popup as proposed.

[mickenordin]

I think this is the problem, doing the same thing in a slightly different way is not good IMHO. I would rather add a new permission, view to the permission scheme, but I think read serves this purpose for a webapp. I think viewMode is a very confusing name for a permission, and permission is there al ready for the other share types, so why not use it. We could remove viewMode and use target instead, along with permission though.

[glpatcern]

Well, read is not the same as view for a webapp. But ok a proper implementation for view would require no webdav sharing. OK to use permission and target, and deprecate viewMode.

[glpatcern]

Fully agree with that - The webapp sharing has been since the beginning related to a specific resource with a specific app.

In that sense, one consequence is that we could envisage - or enforce?! - that a webapp share always comes with a data transport (typically, webdav) share, such that the heavy lifting of access authentication (including code flow where implemented) is already done.

The OpenAPI spec alludes to that, though the phrasing can be improved, and I think a similar sentence was there in the I-D but was removed.

[mickenordin]

Good point!

[glpatcern]

IMHO this approach is too heavy in terms of discovery and options, so here I'm trying to look for simplifications.

In first approximation, the display mode makes for a better UI but it's "cosmetic", and one could imagine that a webapp meant as an embedded popup may just work as full page. Still, if we want to advertise what a Server can do, what about the webapp property of the discovery endpoint?

Which brings another observation: the current webapp in discovery is a string for the "root" URI of all apps, which is indeed not very relevant/useful. We could entirely drop that and instead say what the server can do in terms of targets, something like:

...
  webapp:
    targets:
      - iframe
      - redirect

And then a Sender MAY look into a Receiver's ability to render such targets, or just check that the Receiver is able to process a webapp share and send it off.

[mickenordin]

Yes, I agree that protocols.webapp in the discovery is not useful as is, but I do think the ability to render ui:s in different ways is a capability and it is useful to signal to others as such.

[glpatcern]

I gently disagree :-) capabilities so far are not protocol-specific, whereas here we're giving details about the webapp protocol and its implementation/presentation.

[glpatcern]

This is where my comment about binding the webdav + webapp would make a difference in terms of UX: in our PoC, instead of Bob opens it via the receiving server's UI, we'd have first Bob opens the share via his UI using webdav, and then he would click on Open in remote app, which would trigger the receiving server's UI.

[glpatcern]

For more details about the "user story", we have demonstrated this at the ScienceMesh final event during EGI 2023:

https://www.youtube.com/watch?v=UHAt1K8o70U&t=7489s

[mickenordin]

I will merge this, and we can talk about these points during my presentation at the interim.