-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Goedemorgen,
Het mag duidelijk zijn dat het initiatief van de Nederlandse Spoorwegen om een publieke API beschikbaar te stellen een hele goede is, de NS heeft het voortouw genomen waar anderen duidelijk steken hebben laten vallen en juist dat we met z'n allen hier ons ding mogen doen met zeer schappelijke voorwaarden heeft al tot veel prachtige dingen geleid. Dat er een aantal restricties aan zitten valt in veel gevallen ook nog best te begrijpen, en als eerste aanzet is wat er uit de API zelf komt, misschien esthetisch niet wat je zou willen, maar goed interpreteerbaar. Al ver voor de lancering van de NS API is ons project openOV bezig geweest met 'echte' realtime data en hoe je dat op een elegante manier bij de ontwikkelaar thuis kunt krijgen. Wij denken dan ook dat PULL niet het enige middel is om het doel te bereiken... PUSH zou zeker niet mogen ontbreken. Omdat je immers op het moment dat iets is veranderd geïnformeerd wil worden, en daar niet constant om moet vragen. Wil je met een bepaalde trein of op een bepaalde tijd met de trein? Dan vraag je gewoon of het systeem jou informeert. Conceptueel een vrij makkelijk idee, mits je weet wanneer iets verandert, anders moet je natuurlijk alles blijven 'pollen'. Je zou ook kunnen zeggen 1 persoon moet die polls doen, en dan heeft de rest een PUSH-API. Maar wie gaat dat klusje klaren? En waarmee? Allereerst is ons uitgangspunt geweest dat we _niet_ aan inhoud gaan sleutelen, de NS heeft voor een bepaald berichtenformaat gekozen. Een andere integrator kiest weer wat anders, en kijk je naar de GTFS-realtime specificatie dan is er weer een ander datamodel op geslagen. Laten we gewoon eerst een beginnen met het ontsluiten, in plaats van: herschrijven. Omdat wij ook geen wielen opnieuw gaan uitvinden op het gebied van berichtuitwisselstandaarden valt de keuze al snel op XMPP. Talloze libraries zijn hiervoor beschikbaar, in vrijwel iedere programmeertaal, en is straks ook 'native' in de browser te gebruiken; nu over HTTP(S) via Javascript (BOSH) of Websockets. Wat we wel hebben gedaan? Actuele Vertrektijden en de stationslijst ontsloten. Stationsvoorzieningen zijn keihandig, dus die hebben we er ook maar tussen gestopt. En we hebben een semi-complete mapping naar waar de trein daadwerkelijk stopt en hoe laat (zeg maar de actuele vertrektijden per rit, in plaats van per station) gemaakt. Een kleine wijziging is gedaan voor 'aliases', geen true/false meer, maar gewoon de lijst met aliases op een station zelf. We vinden het ook stom dat je eerst een API key zou moeten hebben om de dienst te gebruik te mogen maken dus hebben we de volgende opties voor je: - - als je een eigen XMPP server hebt kun je automatisch verbinden met je eigen account. Je logt in op je eigen server, en je server regelt de rest. En ja: GoogleTalk is ook een werkende XMPP server. - - op het moment dat we onze webdemo af hebben zorgen we dat een iedereen anoniem kan inloggen, wat niet veel meer zegt dat je gewoon een random gebruikersnaam hebt, zonder wachtwoord. Daarmee hebben we gelijk onze eigen BOSH server en kun je met een js library als Strophe gewoon verbinden. - - omdat we weten hoe vervelend het is dat je niet gelijk aan de slag kunt als je een newbie bent met XMPP, hebben we ook maar gelijk een webinterface gebouwd (alpha), nee het is allemaal niet de bedoeling omdat permanent te gebruiken, maar het geeft je wel even de feeling met wat we aan het doen zijn en hoe het werkt. (zie later in de mail) Wat werkt er nu? We hebben nu de NS calls: stations, storingen, actuelevertrektijden geïmplementeerd. Je kunt je op actuele vertrektijden abonneren via het PubSub model (XEP-0060). Je mag het abonneren beschouwen als beta en iets wat ik goed wil testen, want verder werkt alles als een trein. Hoe werkt dat allemaal? Door middel van 1 NS account, bevragen we de NS eens per tien minuten wanneer er niets aan de hand is, registreert het systeem een vertraging op een bepaald station, gaan we terug naar eens per vijf minuten voor dat station, komt de eerst volgende trein twee uur laten gaan we een uur van te voren weer beginnen met snuffelen, en duurt het nog een uur voordat de eerstvolgende trein komt, kijken we na twintig minuten weer. Dat is de business logica. We maken technisch gebruik van eJabberd (als XMPP server), SleekXMPP (als Python XMPP library), SQLite (voorlopig voor wat opslag van de stationlijst en voorzieningen). De HTTP demo is voor rekening van WebPy, uWSGI en Cherokee. Hoe ziet dat er dan uit? Binnen XMPP heb je mogelijkheid om Service Discovery te doen, en gebruik te maken van een Publish-Subscribe systeem. Service Discovery kun je voorstellen als een map weergave met bestand, pubsub meer als een inhoud weergave. Voorbeeldje: Service discovery: <http://nsapi.xmpp.openov.nl/stations/vb/> ============================================================= <query xmlns="http://jabber.org/protocol/disco#items"; node="stations/vb"> <item node="stations/vb/avt" jid="nsapi.xmpp.openov.nl" name="Actuele Vertrektijden"/> <item node="stations/vb/vz" jid="nsapi.xmpp.openov.nl" name="Voorzieningen"/> <item node="stations/vb/storingen" jid="nsapi.xmpp.openov.nl" name="Storingen en Werkzaamheden"/> </query> PubSub: <http://nsapi.xmpp.openov.nl/stations/vb> ================================================= <items xmlns="http://jabber.org/protocol/pubsub"; node="stations/vb"> <station> <name>Voorburg</name> <code>vb</code> <country>NL</country> <lat>52.066294</lat> <long>4.359480</long> </station> </items> Het schema van de nodes in XMPP (en daarmee de URL in de demo) zien er zo uit: stations (stationslijst) stations/_code_van_station (info over het station) stations/_code_van_station/avt (actuele vertrektijden) stations/_code_van_station/avt/_ritnummer_ (avt, voor 1 rit) stations/_code_van_station/vz (Voorzieningen) stations/_code_van_station/storingen (Storingen/Werkzaamheden) treinen (alle data die nu bij ons is uit avt) treinen/_ritnummer (algemene info) treinen/_ritnummer/avt (actuele vertrektijden, semi-compleet) Ter lering en de vermaeck; <http://nsapi.xmpp.openov.nl/stations/ut/avt/> <http://nsapi.xmpp.openov.nl/stations/ut/avt> Dit mailtje is natuurlijk al weer veel te lang geworden. Maar nog even waarom we dit doen. We willen _heel graag_ dat de NS zelf, een XMPP PubSub faciliteert voor iedereen, zodat iedereen met z'n eigen authenticatie kan inloggen de NS weet waar het verkeer vandaan komt, etc. Daar mogen ze onze open source code natuurlijk voor gebruiken. Eigenlijk willen we die dienst voor het hele OV hebben, en zijn we hard op weg om ook het busvervoer op een zelfde manier te ontsluiten. We hebben nog wel wat verzoekjes, want diegene die gaat speuren komt nog wat mooie conceptuele ideeën tegen. Bugs, feature requests, meehelpen? Uiteraard gewenst! :) Stefan openOV -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk5qwaoACgkQYH1+F2Rqwn2OCACgizSZ7/XosycQ1lIq2qXYUfBp NysAmwTsFGtgvhAHl5hPSpT4WdlIu65Q =q7nW -----END PGP SIGNATURE----- _______________________________________________ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
