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
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
