Markdown Historie.
Jedes gespeicherte Markdown erhaelt eine historie ueber die jede vergangene Version eingesehen werden kann. Gespeichert ist diese in Form eines komprimierten diffs.
Die Frontend Komponente kann jede beliebige existierende Patchversion darstellen. Auf der Datenseite ist aber kein undo möglich. Genau wie man in der Realität nicht in der Zeit zurück gehen kann kann man das auch nicht mit den Inhalten. Würde man das zulassen, so würde entweder ein Teil der Historie des Markdowns wegfallen müssen oder aber es würde ein beliebig komplexer Baum von Histoien entstehen.
Statt also ein undo auf eine frühere Version zuzulassen kann man in der aktuellen Version auf frühere Stände zurück gehen und diese gegebenenfalls noch anpassen. Dieser Stand wird wieder ein neuer Patch gegen die gegenwärtige Version.
Gedanken zum file upload.
Der finale Dateiname sollte ein eindeutiger Hashwert des content sein. Um die erzeugung des Hash schnell zu halten sollte es ausreichen nur einen Teil vom Anfang und von Ende und der Mitte zu hashen. Das habe ich schon mal in einem anderen Projekt gemacht... [SUCHE]
Die Dateien sollten dann in einem zweistufigem Verzeichnisbaum gespeichert werden bei dem die Verzeichnisse mit den ersten Zeichen des Hashs beginnnen.
Weitere Metainformationen wie Dateiname, Mime-Type, etc. werden in der Datenbank gespeichert.
Die ausgelieferten Bilder sollen eine steganographisch eingebettet Copyright Information enthalten oder aber mit einem Wassermark versehen sein. Es gibt ein rust crate steganography das für die erste Anwendung geeignet scheint. Für die zweite Anwendung ist evtl. photon_rs geeignet.
Uploads ueber die fetch API koennen zur Zeit scheinbar nicht wirklich einen Progressbar haben. Daher werde ich wohl einen spinner anzeigen und dann Error oder Ok...
Some older notes taken from the server source file
This diesel based webservice this server is derived from is from the webpage: Creating and API with rust and sqlite I have fixed some things manually as the code on that page did not compile without.
Additional informations at Actix Databases assume one should use web::block to access the database...
TODO check what is the difference to this approach.---well, we use
web::block already for write actions.
Introduction to rust async:
Simple explanation on technical terms synchronous, asynchronous, concurrent and parallel: synchronous vs. asynchronous vs. concurrent vs. parallel