Skip to content
This repository has been archived by the owner on Jun 28, 2021. It is now read-only.

Improve handling of bundled md #9

Open
glpatcern opened this issue May 5, 2021 · 1 comment
Open

Improve handling of bundled md #9

glpatcern opened this issue May 5, 2021 · 1 comment

Comments

@glpatcern
Copy link
Member

glpatcern commented May 5, 2021

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.
  1. 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.

@glpatcern
Copy link
Member Author

glpatcern commented Jun 25, 2021

Update following further inputs:

  1. There's some consensus to ditch this .zmd file type, as preserving shared links and versions/revisions is important.
  2. Another option is to exploit the soon-to-come "file picker" interface in ownCloud, and make sure files embedded in CodiMD are actually already present in the cloud storage. In that case, we just keep the .md file and that's all.

This last option requires quite some developments:

  • On ownCloud/CERNBox, a file picker UI with the ability to create a public link on the fly, such that the result returned to CodiMD is a link of the form https://cernbox.cern.ch/index.php/s/<hash>/download.
  • On CodiMD, replacing the "upload file" dialog with the file picker when in appliance mode. The /uploads folder in CodiMD would be entirely "disabled".

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

No branches or pull requests

1 participant