Feature #1115

XML-Interface aktualisieren

Added by following about 3 years ago. Updated about 3 years ago.

Status:neu% Done:

0%

Priority name:1 niedrig
Assignee:-
Target version:-
Ticket Referenz: Kategorien:export

Description

Im XML-Interface fehlen einige neue Informationen, insbesondere die Cachelisten. Denke es lohnt sich, diese Schnittstelle zu pflegen; siehe auch Beitrag dazu im Teamforum.

[nicht vergessen: gelöschte Cachelisten => removed_objects)

Prio abhängig davon, ob #25 realisiert wird.


Related issues

Blocks OC Entwicklung - Feature #25: XML-Datenimport von OC.de im Entwicklersystem offen

History

#1 Updated by following about 3 years ago

  • Blocks Feature #25: XML-Datenimport von OC.de im Entwicklersystem added

#2 Updated by teiling88 about 3 years ago

Wäre das für dich in Ordnung wenn man das ganze auf die neue Struktur portiert und JSON anstatt XML verwendet?

#3 Updated by following about 3 years ago

Ich verstehe den Sinn dieses Vorschlags, allerdings hätte das für mich ausschließlich Nachteile im Vegleich mit der schnell gemachten eigenen Ergänzung des XML-Interface:

  • Mehraufwand für die Kommunikation der Anforderungen.
  • Mehraufwand für das Testen und Debuggen der neuen API (XML ist grundsätzlich ausgereift und stabil).
  • Eine weitere Baustelle, bei der ich auf andere Entwickler warte und ausgebremst werde - davon gibt es schon zu viele. (#25 und #1115 ist eng verzahnt, es kann im Laufe von #25 neue Anforderungen an die API geben. Dito bei zukünftigen Ergänzungen in der OC-Datenbank.)
  • Es ergäbe nur Sinn, wenn man das XML-Interface abschaltet, das aber weiterhin z.B. von OC-Clean und Cachewolf genutzt wird.

Also ich würde dann vorschlagen, dass derjenige der die API portiert auch gleich noch #25 übernimmt. :-) Außerdem würde ich statt einer 1:1-Portierung eine Bestandsaufname und Renovierung der Schnittstelle empfehlen - manches könnte entfallen, da redundant zur OKAPI, anderes lässt sich verbessern.

#4 Updated by teiling88 about 3 years ago

Es ergäbe nur Sinn, wenn man das XML-Interface abschaltet, das aber weiterhin z.B. von OC-Clean und Cachewolf genutzt wird.

Langfristig ist das der Plan.

Also ich würde dann vorschlagen, dass derjenige der die API portiert auch gleich noch #25 übernimmt. :-) Außerdem würde ich statt einer 1:1-Portierung eine Bestandsaufname und Renovierung der Schnittstelle empfehlen - manches könnte entfallen, da redundant zur OKAPI, anderes lässt sich verbessern.

Dann nenne mir bitte die Funktionen die Du von der XML Schnittstelle für OCC verwendest damit man die Migration planen kann.

#5 Updated by following about 3 years ago

Wenn #25 fertig und ausgereift ist - Erstreplikation der öffentlichen OC-Inhalte und inkrementelle Updates - dann sind alle Features und Inhalte verfügbar, die jetzt oder in Zukunft von OCC genutzt werden.

Ausgereift heißt: Wenn man www.opencaching.de damit repliziert, anschließend ein paar Monate lang mehrmals täglich inkrementelle Updates einspielt, und das Ergebnis ist - soweit vorgesehen - identisch mit dem Original dann ist es ausgereift. Unvollständige oder fehlerhafte Daten können wir uns bei OCC nicht leisten.

#6 Updated by following about 3 years ago

Oops, es wird doch noch ein Feature genutzt dass für #25 überflüssig ist: Das selektive Replizieren nach Objekttyp (Caches, Logs usw.). Damit lässt sich das Datenvolumen der laufenden Replikation auf einen Bruchteil reduzieren, aber für bestimmte Einzelprüfungen (die auf einem anderen Host laufen) ist trotzdem alles verfügbar.

#7 Updated by following about 3 years ago

Was ich auch nutze ist die Möglichkeit, an einem beliebigen Datum aufzusetzen. Das ist sehr hilfreich beim Debuggen von OC-Clean, weil sich die Änderungen in dem Zeitraum reproduzieren lassen in dem ein Problem aufgetreten ist.

Siehe auch #25: "Wer seine Datenbank kompakt halten will, kann sich auch nur die Daten ab Tag X ziehen."

#8 Updated by following about 3 years ago

Außerdem würde ich statt einer 1:1-Portierung eine Bestandsaufname und Renovierung der Schnittstelle empfehlen - manches könnte entfallen, da redundant zur OKAPI, anderes lässt sich verbessern.

Das meinte ich natürlich nur für den Fall, dass die XML-Schnittstelle erhalten bleibt. Wenn sie ersetzt werden soll, dann muss die neue Implementation bei identischem Input einen identischen oder abwärtskompatiblen Output liefern, damit die bestehenden Anwendungen weiter funktionieren.

#9 Updated by following about 3 years ago

Das XML-Interface wird meines Wissens noch genutzt von

  • geokrety.org
  • Cachewolf
  • GeOrg
  • OCC

Also available in: Atom PDF