This repo and its functionality has been merged in the WOPI server repo, therefore it is now frozen.
This is a proof-of-concept WOPI bridge server, currently only targeting CodiMD, to allow bridging it to a WOPI-enabled EFSS service like ownCloud or CERNBox. It uses the private REST API of CodiMD, which will be hopefully made public and complete in the future. The approach is generic to allow for extending the concept to other Office-like applications exposing a minimal load/save REST API.
- REST service with two endpoints:
/openmeant to be called by the EFSS with a WOPISrc and a WOPI access token, returns a file displayed in CodiMD/saveauto-called by the CodiMD backend when some changes are detected on the open document
- Stateless server, all context stored in the WOPI lock or passed through arguments
- Readonly (publish or slide) mode vs. read/write mode
- Collaborative editing and locking of the file
- Transparent handling of uploads (i.e. pictures):
- If a note has no pictures, it is handled as a
.mdtext file - Once a picture is included, on close the save to WOPI is executed as a zipped bundle, with a
.zmdextension, and the previous.mdfile is removed; similarly if all pictures are removed and the file is saved back as.md - Files ending as
.zmdare equally treated as zipped bundles and expanded to CodiMD
- If a note has no pictures, it is handled as a
/newpush a new file to a random<noteid>/<noteid>display a file, or reserve a<noteid>if not existing/<noteid>/publishdisplay a file in readonly mode/<noteid>/slidedisplay a file in slide mode/<noteid>/downloadget a raw file to store it back/uploadimageupload a new picture/uploads/upload_<hash>get an uploaded picture/api/notes/<noteid>update a file via PUT
GetFileInfo: get all file metadataGetFile: get the file contentGetLock: check if the file is lockedLock: lock a file on open for writePutFile: store a file's contentPutRelative: store a file under a different nameUnlock: unlock a file on closeDelete: delete a previous edition of a file