Option zum Auslassen von eingebetteten Listen mit einem Filter für #396

[konstin]

@sterni24 @Medo42 Ich habe mit den Ergebnissen aus der Diskussion in #396 einen Entwurf für einen Parameter omit_internal geschrieben.

[Medo42]

Ich glaube hier wäre zusätzlich auch Paper.consultation betroffen. Und guter Einwand zu agendaItem, wobei gerade das eine der "schwergewichtigsten" inneren Listen ist.

Wenn man die AgendaItem-Liste für Updates zumindest auf die Reihenfolge reduzieren will, könnte man eine neue Eigenschaft einführen (agendaItemOrder?) die dann im Update-Modus die agendaItem-Eigenschaft ersetzt und eine klassische Liste von URLs ist. Die naheligende Idee, diese Liste direkt in der agendaItem-Eigenschaft anzugeben, fände ich aus praktischen Gesichtspunkten nicht ganz so schön. Wenn die Eigenschaft in verschiedenen Kontexten verschiedene Formate annehmen kann, dann braucht man je nach Ansatz auch im Code zwei verschiedene Klassen für das Meeting.

[sterni24]

Wofür benötigt man eine agendaItemOrder? Welche verschiedenen Kontexte / Formate gibt es?

[akuckartz]

Ich fände es hilfreich, wenn Vorschläge wie ‘agendaItemOrder‘ in separaten Issues gemacht würden.

[Medo42]

@akuckartz Ich sehe das schon als eine Diskussion zu diesem konkrenten Vorschlag von @konstin.

Wofür benötigt man eine agendaItemOrder?

@sterni24 Die Idee ist meinem Verständnis nach, dass man alle Objektlisten mit omit_internal-Parameter und passenden Datumsfiltern abfragt, um ein inkrementelles Update des Datenstands zu erhalten. Durch den omit_internal-Parameter soll vermieden werden, dass redundante Informationen übertragen werden (weil die internen Objekte ja schon in ihrer eigenen Objektliste auftauchen wenn sie sich geändert haben). Wenn man aber die AgendaItems-Liste aus dem Meeting weglässt, dann erhält man bei dem oben genannten Vorgehen (alle Objektlisten mit omit_internals abfragen) an keiner Stelle mehr eine (strukturierte) Information über die Reihenfolge der AgendaItems.

Mal angenommen, zur Tagesordnung eines geplanten Meetings kommt nach der Begrüßung ein neues AgendaItem "Gastrede" hinzu. Bei der Abfrage der geänderten Meetings mit omit_internals würde man in dem Meeting keine Änderung erkennen, wenn die Liste der AgendaItems nicht mitgesendet würde. Bei der Abfrage der geänderten AgendaItems würde man das neue AgendaItem "Gastrede" erhalten, und auch die Zuordnung zum richtigen Meeting, aber man wüsste nicht an welcher Stelle im Ablauf der Tagesordnung es eingefügt werden muss. Durch das Weglassen der AgendaItem-Liste aus dem Meeting würde also nicht nur redundante sondern essenzielle Information verloren gehen, und darum hat @konstin in seinem Vorschlag geschrieben, dass diese interne Liste nicht weggelassen werden darf.

Das ist aber wiederum ungünstig, weil gerade die AgendaItem-Liste in der Regel relativ viele Daten enthält. Darum habe ich darauf hingewiesen, dass man diese Liste doch weglassen könnte, wenn man die darin enthaltene nicht-redundante Information (die Reihenfolge der AgendaItems) auf andere Weise überträgt, wenn die eigentliche agendaItems-Liste weggelassen wird. Das könnte erreicht werden, indem man statt der Liste der AgendaItems eine Liste von AgendaItem-IDs im Meeting-Objekt überträgt (also ein array of url (AgendaItem), wie es in der Spezifikation heißen würde). Um es ganz konkret auszudrücken (angelehnt an die Spezifikationsformulierungen): Der Server soll bei Verwendung von omit_internal=true die agendaItem-Liste im Meeting-Objekt weglassen. In diesem Fall muss er allerdings eine Liste der AgendaItem-IDs übertragen, die die AgendaItems in der gleichen Reihenfolge enthält, mit der sie in der internen agendaItem-Liste erscheinen würden.

Welche verschiedenen Kontexte / Formate gibt es?

Der letzte Teil meines Kommentars ging eigentlich schon zu tief ins Detail. Es ging lediglich darum, dass manche es naheliegend finden könnten, die oben genannte Liste der AgendaItem-IDs ebenfalls unter dem Eigenschaften-Namen "agendaItem" zu übertragen. Dann könnte diese Eigenschaft allerdings entweder eine interne Objektliste enthalten (wenn das Meeting-Objekt "normal" ausgegeben wird) oder eine Liste von URLs (wenn der Client omit_internal=true angibt und der Server die Ausgabe der internen agendaItems-Objektliste unterdrückt). Das ist das, was ich mit den verschiedenen "Kontexten" gemeint hatte (normale Abfrage oder Update-Abfrage).

Weil es zumindest in unserem Client-Code umständlicher wäre wenn eine Eigenschaft mit dem gleichen Namen manchmal eine interne Objektliste ist und manchmal eine Liste von URLs, gehe ich davon aus, dass auch andere Client-Entwicker (und vielleicht auch Server-Entwickler) es bevorzugen würden, für die Liste von AgendaItem-URLs einen anderen Namen zu verwenden als für die interne Objektliste. Darum hatte ich den Eigenschaftennamen agendaItemOrder ins Spiel gebracht.

Ich hoffe damit ist mein Kommentar nun verständlicher. Das ganze war nur als kurzer Hinweis auf einen möglichen Lösungsansatz gedacht.

[sterni24]

@Medo42 vielen Dank für die Erläuterungen.

Der Update-Mechanismus holt uns wieder ein! Hier ein Auszug aus der Diskussion #125 zur Sortierung der agendaItems:

siehe #398

[akuckartz]

Da https://github.com/OParl/spec/issues/125#issuecomment-41666554 erwähnt wurde erlaube ich mir eine Randbemerkung: Ja, das war damals die saubere Lösung und basierend u.a. auf #165 wäre auch ein einfacher und nachhaltiger Update-Mechanismus möglich gewesen. Aber OParl wollte danach ja unbedingt schnell eigene Spezial-Lösungen schaffen statt generische zu nutzen (historisch Interessierte finden etwas Hintergrund in #237).