[Talk-de] API 0.6

Frederik Ramm frederik at remote.org
Di Nov 18 13:49:31 UTC 2008


Hallo,

    für die, die die Entwicklung nicht verfolgen, hier ein kurzer Abriss 
darüber, was mit API 0.6 kommen wird. Die Einführung ist um die 
Weihnachtszeit geplant und wird mit einer mehrtägigen Auszeit verbunden 
sein.

Wenn jemand in einem Forum mitliest, in dem das interessant sein könnte, 
gern auch dorthin übernehmen.

* Relationen geordnet - die API wird künftig die Elemente einer Relation 
in der Reihenfolge zurückgeben, wie man sie reingestopft hat. Dadurch 
wird man z.B. eine Busroute und ihre Haltestellen ordentlich abbilden 
können, ohne dass man als "role" sowas wie "stop_1", "stop_2", "stop_3" 
usw. nutzen muss.

* Limits für die Größe von Ways und Relationen - so größenordnungsmäßig 
nicht mehr als 2000 Nodes pro Way und nicht mehr als 2000 Members pro 
Relation. Existierende, die größer sind, können noch heruntergeladen, 
aber nicht mehr verändert werden. Eventuell machen wir auch vorher noch 
eine Zerhack-Aktion, damit es keine größeren mehr gibt.

* Transaktionalität im Backend - keine Diskrepanzen zwischen "current"- 
und "history"-Tabellen mehr, garantierte referentielle Integrität.

* "optimistic locking" - Die Änderung eines Objekts wird künftig nur
noch erlaubt, wenn die Anfrage sich auf die richtige Versionsnummer 
bezieht. Hierdurch wird das Szenario "User A lädt Daten herunter, 
bekommt Version 5 des Objekts, User B lädt herunter, bekommt auch 
Version 5, User B macht Upload (ergibt Version 6), User A macht Upload 
und überschreibt Arbeit von B" vermieden; User A wird künftig eine 
Fehlermeldung ("409 Conflict" o.ä.) erhalten. - Als kleinen für 
Programmierer bedeutenden Seiteneffekt bringt diese Änderung mit sich, 
dass alle modifizierenden API-Calls inklusive der HTTP-DELETE-Methode 
nun eine Nutzlast (einen Request Body) tragen müssen. Dies ist mit dem 
HTTP-Standard konform, aber nicht alle HTTP-Libraries unterstützen 
Nutzlast bei DELETE (z.B. die Standard-Java-Implementation kanns nicht).

* Changesets - Änderungen müssen künftig zwangsweise in Gruppen 
zusammengefasst werden. Eine Änderung kann nur hochgeladen werden, wenn 
sie sich auf eine gültige solche Gruppe - ein "Changeset" - bezieht. 
Beim Erzeugen eines Changesets muss ein Kommentar (ähnlich einem 
Commit-Kommentar in einem Versionskontrollsystem) eingegeben werden. 
Changesets haben ein begrenztes Fassungsvermögen und eine begrenzte 
Lebensdauer. Datenbank-intern wird für ein Changeset mitprotokolliert, 
welches Rechteck auf der Karte von diesem Changeset insgesamt betroffen 
ist. Abfragefunktionen ermöglichen es später, eine Liste aller 
Changesets für ein bestimmtes Gebiet abzurufen. Datenbank-intern wandern 
auch einige Dinge, die bislang pro Objekt gespeichert wurden - Username 
und "created_by" - in die Changeset-Tabelle (Changesets können beliebige 
Tags haben). Changesets sind nicht atomar/transaktional.

* Diff-Upload - das bereits verbreitete "osmdiff"-Format, in dem auch 
die täglichen diffs generiert werden und das von Osmosis unterstützt 
wird, kann nun auch für Uploads an den Server benutzt werden, d.h. man 
kann eine größere Menge Änderungen in einem diff-File zusammenstellen 
und dieses dann in einem einzigen Vorgang hochladen. Diff-Uploads sind 
transaktional, d.h. wenn eine einzige Änderung im Upload schiefgeht, 
wird keine aktiv.

Alles in allem wird das ein Riesenschritt vorwärts. Leider ist noch 
nicht ganz klar, ob performancemäßig alles so läuft, wie wir das 
erwarten, hier müssen noch Tests geschrieben und durchgeführt werden, 
das Cloudmade-Team (Andy Allan, Shaun McDonald, Matt Amos) arbeitet 
daran. Mit API 0.6 würden die lezten verbliebenen MyISAM-Tabellen 
rausgeworfen und komplett auf InnoDB gesetzt; MySQL-Experten wissen, was 
das bedeutet.

Durch die Changesets wird viel für Rollback und Anti-Vandalismus 
vorbereitet, allerdings unterstützt die API selber keinen 
Rollback-Mechanismus. Es wird also der Programmierer-Community zufallen, 
hier Software zu schreiben, die es dem User erlaubt, relevante 
Changesets herunterzuladen und zu inspizieren und dann auf eins zu 
klicken und zu sagen "dies will ich rückgängig machen", dann ein 
geeignetes "diff" zu erzeugen und dies an die Datenbank zu senden. Im 
simpelsten Fall ist so ein diff wirklich einfach das "Changeset 
rückwärts", aber kompliziert wird es, wenn einige Dinge in der 
Zwischenzeit von anderen verändert wurden. Hier wird es sicherlich eine 
lange Entwicklung geben, bis wir da richtig gute Tools bekommen.

Parallel und weithin unbemerkt ist der Ruby-Code auch von sämtlichen 
MySQL-Spezialfällen bereinigt worden, so dass die API nun zumindest 
theoretisch auch auf PostgreSQL läuft (zunächst ohne 
PostGIS-Extensions). Wer Spass daran hat, kann sich den aktuellen Code 
aus dem SVN ziehen und damit spielen (Bugreports zu Postgres an Andy 
Allan). Es ist nicht geplant, bei der Umstellung auf API 0.6 auch gleich 
auf PostgreSQL zu gehen, aber die Sache wird weiter verfolgt, vorallem 
auch, um was in der Hinterhand zu haben, falls die MySQL-Performance 
nicht akzeptabel ist.

Und abschliessend: Ich bin *nur* der Überbringer dieser Botschaft, ich 
habe selbst nur ein paar kleine Sachen zu 0.6 beigetragen; Lob oder 
Tadel also nicht an mich, ausser ihr wollt danke sagen, dass jemand mal 
alles zusammengeschrieben hat oder meinen Duktus kritisieren ;-)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"




Mehr Informationen über die Mailingliste Talk-de