cs3org / wopibridge Goto Github PK

Noting this here for the record, to be addressed possibly after reimplementing this component in Go.

Currently, if the WOPI lock is missing (the call to retrieve it fails), md documents are not saved and the user is requested to copy/paste the content by hand and reopen the document to recover it.

An improvement could be to still try and save a _conflict file for the user, and then issue a warning like "please check and merge the content". This can be achieved with a PUT_RELATIVE WOPI call, provided that the WOPI access token is still valid.

A better alternative: try and take again the WOPI lock (provided the WOPI access token is still valid), and overwrite the file. The only issue is the file might have been overwritten by other users outside of CodiMD, if shared, but the UX is definitely more seamless: one can work on a file, disconnect (e.g. by closing the lid), reconnect later and keep working.

If the WOPI token is not valid any longer, a message needs to be displayed to tell the user to refresh the page, possibly signing in again via SSO.

In case the remote storage is unreachable or the WOPI session has expired, we may end up with a valid document that cannot be saved.

We should at least save it to some temporary local storage, in order to help with later recovery by operations - or ideally have a mechanism to renew the WOPI access token.

In the code, this corresponds to two comments marked as:
TODO here we should save the file on a local storage to help later recovery!

Currently, markdown documents including pictures are saved to/retrieved from the storage as a bundled .zmd (for zipped markdown) file. However this solution has a number of issues:

• The system renames the file from .md to .zmd (and viceversa) depending on the presence (or absence) of embedded pictures, but this happens "on the back of the user", so it may look counter-intuitive.
• If the file was shared when .md, the share link gets broken.
• Text content is zipped and not indexable by OSs when the file is synchronized.

We should look into alternatives to preserve the filename. For instance:

1. Always save a .md and put the pictures alongside in the same folder, similar to browsers saving a complete HTML page (though they'd use a folder, which we cannot). Issues:

• We'd need to keep the pictures on the CodiMD server as well, because when pushing the file from the EFSS to CodiMD the wopibridge cannot access other files in the folder.
• To keep the content in sync, the pictures would need to be deleted and recreated at each save+close operation.
• Risk of polluting the target folder with many pictures.

2. Always save a .md, pictures are only kept on the server and never synchronized.

• Users never have their embedded pictures offline.
• We could define a special "tag", e.g. [](embed-pictures) which is not rendered: if found at the top of the document, the file is saved as .zmd and the user gets the whole content.

Out of the above, my preference is to implement 2 as that would fix the current issues and keep the solution simpler to the user, though the [](embed-pictures) tag would need to be documented and is kind of an advanced feature.

To be noted that in all cases it is not expected that users modify the file outside of the app, therefore in particular the first issue in 2. may not be such a big deal.