0qln
ce0875f29b
Zwei Kompressionsdurchgaenge ueber Kapitel 2-7. Entfernt wurden Redundanzen, Meta-Kommentare, Ueberklaerungen und Fuellsaetze; Fakten, Namen, Daten, Entscheidungen samt Begruendung sowie alle Abbildungen und Tabellen bleiben unveraendert. Reine Textseiten: 78 -> 57 (Woerter 19613 -> 12451). Gesamt-PDF: 138 -> 116 Seiten.
45 lines
3.5 KiB
TeX
45 lines
3.5 KiB
TeX
\section{Ausblick}
|
|
\label{sec:outlook}
|
|
|
|
\subsection{Abschluss der begonnenen Arbeiten}
|
|
|
|
Die nächsten Schritte ergeben sich aus Abschnitt~\ref{sec:target-comparison}.
|
|
|
|
Zusammenzuführen ist der Pull Request zur Ordnerverwaltung, womit die automatische Ordneranlage und der Lookup mit konstanter Aufrufzahl wirksam werden. Da die Lösung bestehende Ordner selbsttätig umbenennt, entfällt ein Migrationsschritt.
|
|
|
|
Zu beheben ist der Abnahmefehler zur Einheitlichkeit des Suchfeldes, eingeplant für den folgenden Sprint.
|
|
|
|
\subsection{Absicherung des verändernden Lookup-Pfads}
|
|
|
|
Die in Abschnitt~\ref{sec:race-conditions} beschriebene Nebenläufigkeit ist das gewichtigste offene Thema. Das Backlog Item ist freigegeben und mit vier bis sechs Stunden veranschlagt.
|
|
|
|
Welche Maßnahme umgesetzt wird, hängt davon ab, ob der Speicher bedingte Schreibvorgänge unterstützt.\autocite{aws-conditional-writes} Steht die Funktion bereit, ist die Absicherung einfach; andernfalls bleiben die Absicherung des Rücknahmeschritts und eine übergreifende Sperre.
|
|
|
|
Unabhängig davon ließe sich der verändernde Anteil aus dem Anfragepfad in einen eigenen, einmalig ausgeführten Vorgang lösen; der Lookup könnte dann auf reines Lesen zurückgeführt werden.
|
|
|
|
\subsection{Suchdienst des Speicherherstellers}
|
|
|
|
Der in Abschnitt~\ref{sec:lookup-research} betrachtete Suchdienst\autocite{storagegrid-search-integration} wurde vom Betreiber nicht bereitgestellt; ein Folgetermin war vorgeschlagen, aber nicht durchgeführt.
|
|
|
|
Sollte der Dienst verfügbar werden, ließe sich der Kundenordner-Lookup über eine Metadatenabfrage lösen — die eigene Konstruktion bliebe als Rückfallebene. Zudem könnte die Dokumentensuche serverseitig erfolgen statt anwendungsseitig. Beides sind Optimierungen; die bestehende Umsetzung funktioniert, skaliert aber schlechter.
|
|
|
|
\subsection{Fachliche Erweiterungen}
|
|
|
|
In der Feature-Beschreibung sind zwei Erweiterungen genannt, die nicht in Backlog Items überführt wurden.
|
|
|
|
Die erste betrifft die \textbf{Einbindung in die Übersichtsseite} — etwa eine Kachel mit zuletzt hinzugefügten Dokumenten oder Sicherheitsbewertungen. Für Letztere wäre ein auswertbares Merkmal pro Dokument nötig, das mit der bestehenden Struktur (Typ über den Ordner) nicht abbildbar ist.
|
|
|
|
Die zweite betrifft die \textbf{Bereitstellung von Abrechnungsdaten}. Fachlich ist zu klären, ob diese über den Dokumentenbereich oder eine gesonderte Ansicht erfolgen, da sie sich in Herkunft und Aktualisierungsrhythmus von den übrigen Dokumenttypen unterscheiden.
|
|
|
|
\subsection{Bedienung durch die interne Fachseite}
|
|
|
|
Die Entscheidung, die Dokumentenpflege über den externen Dateibrowser abzuwickeln, war für den Projektzeitraum richtig, aber bewusst als Zwischenlösung getroffen. Sollte die Pflege häufiger oder von mehr Personen übernommen werden, wäre eine Verwaltungsoberfläche im Portal zu bewerten — sie könnte die Ordnerstruktur erzwingen statt auf manuelle Einhaltung zu setzen.
|
|
|
|
\subsection{Übertragbarkeit}
|
|
|
|
Das Projekt hat zwei wiederverwendbare Bausteine hervorgebracht.
|
|
|
|
Der \textbf{Zugriff auf den Objektspeicher} ist als eigener Dienst gekapselt und nicht auf Dokumente zugeschnitten; weitere Anwendungsfälle können darauf aufsetzen.
|
|
|
|
Die \textbf{Muster für Freigabelinks und Vorschaubilder} — Pfadkodierung, eingeschränkte Auslieferung auf einem nicht angemeldeten Endpunkt, Bereitstellung in einem von Kommunikationsanwendungen unterstützten Format — lassen sich für andere teilbare Inhalte wiederverwenden.
|