[Talk-de] API 0.6

[DarkAngel]

Frederik Ramm schrieb:
> 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
> 

Danke ;-)
-- 
Gruß Mario