Home
room is publicly logged: http://chat.jones.dk/logs/
talks@conference.jones.dk
Friday, April 29, 2011< ^ >
Room Configuration
[05:37:53] Chatroom is destroyed
[05:37:53] Chatroom is stopped
[05:38:06] Chatroom is created
[05:38:06] Chatroom is started
[05:38:06] nagzilla joins the room
[08:05:00] jonas@jones.dk joins the room
[08:07:41] Siri joins the room
[09:13:16] stoejski joins the room
[09:13:24] <jonas@jones.dk> halløjski!
[09:13:41] <stoejski> og en god dag
[09:13:44] <jonas@jones.dk> ja
[09:14:10] <Siri> Hey
[09:14:13] <jonas@jones.dk> bliver vi flere end os tre 8plus Nagzilla)?
[09:14:37] <stoejski> vi skal mødes med knud ang. sms
[09:14:38] [knud] joins the room
[09:14:45] <jonas@jones.dk> hej K!
[09:14:51] <stoejski> ikke hjemmeside¨
[09:14:51] <[knud]> hep
[09:14:52] <Siri> hi
[09:15:04] <jonas@jones.dk> ah
[09:15:15] <Siri> så ikke webdesign
[09:15:27] <Siri> ?
[09:15:33] <stoejski> nope
[09:15:41] <Siri> nå, nu faldt ti-øren
[09:15:53] <Siri> jeg læste hvad du skrev, Støj
[09:16:12] <Siri> hej igen, så
[09:16:20] <stoejski> en god dag til dig
[09:16:26] <[knud]> hej :)
[09:16:26] <jonas@jones.dk> tarrk
[09:16:37] <stoejski> krrat
[09:16:41] <jonas@jones.dk> sms!
[09:16:45] <stoejski> yep
[09:16:54] <jonas@jones.dk> Jeg er igang...
[09:17:06] <stoejski> jeg har ikke fået fat på jesper, men genstarter bj2
[09:17:20] <jonas@jones.dk> fint
[09:17:35] <stoejski> nå nej det var bj3
[09:17:46] <jonas@jones.dk> jeg er nået til at sms'er sendt til min Kannel sms server nu dukker op som blog-indlæg her: http://msg.delebilfonden.dk/feeds/+4540843136
[09:18:34] <jonas@jones.dk> jeg mangler at få fikseret hvordan indholdet formatteres
[09:18:49] <jonas@jones.dk> og her er det netop væsentligt at kunne teste med de rigtige telefoner
[09:19:04] <jonas@jones.dk> så meget godt at få bare een af dem igang nu
[09:19:34] <jonas@jones.dk> Min plan er at Knud trækker sms info med AtomPub protokollen
[09:20:19] <[knud]> trækker? - altså poller?
[09:20:25] <jonas@jones.dk> dvs. hvis der skal hentes en "seneste status fra hver bil" så gøres det lissom når der hentes et Atom feed
[09:20:36] Siri leaves the room
[09:21:28] <jonas@jones.dk> ...og hvis der skal hentes en "dugfrisk info fra een bil" så _oprettes_ der et AtomPub indlæg med en http POST
[09:21:44] <stoejski> altså knud kommer med telefonnummer og kommandoen
[09:22:10] <jonas@jones.dk> begge dele er mulige
[09:22:43] <stoejski> og nogengange kommer der en sms fra bilen til serveren
[09:22:54] <[knud]> jeg er ikke skker på at jeg forstår helt - kan vitage nogle konkrete eksempler?
[09:22:55] <stoejski> jeg starter bare helt fra scratch her
[09:23:08] <[knud]> ok - jeg lader støj snakke :)
[09:23:15] <jonas@jones.dk> hvis Knud vil at Hvitsærk bliver "prikket til" så opsæt en PubSubHubbub service, så knytter jeg mit AtomPub feed dertil!
[09:23:29] <jonas@jones.dk> ok
[09:23:45] <stoejski> en hvadfåen hubsubbb
[09:24:09] <jonas@jones.dk> nyeste hotte skud på Atom stammen. Forkortes PUSH
[09:24:29] <jonas@jones.dk> Et opsamlingspunkt for Atom feed aggregators
[09:24:32] <stoejski> skal vi tage communic. fra bilen først
[09:24:37] <jonas@jones.dk> gerne
[09:25:16] <stoejski> en bil sender en sms til gateway, knud skal bruge nummeret af bilen (telefonnummer) og indholdet af sms'en
[09:25:24] <jonas@jones.dk> ok
[09:25:36] <jonas@jones.dk> mit system modtager sms'en,
[09:25:46] <jonas@jones.dk> og opretter et blog-indlæg med den
[09:26:17] <jonas@jones.dk> ...og kan gerne sende en http "ping" til Hvitsærk
[09:26:41] <jonas@jones.dk> (i mangel af pubsubhubbub, som jeg gætter på Knus ikke lige er i humør til at bakse med nu)
[09:27:08] <stoejski> correct
[09:27:13] <jonas@jones.dk> Hvitsærk modtager altså en "der er nyt på bloggen"
[09:27:35] <jonas@jones.dk> ...og kan med en http commando hente det
[09:28:06] <jonas@jones.dk> Data på bloggen ligger i XML format
[09:28:16] <[knud]> det lyder jo enkelt - du kunne jo sende indholdet med ping'et for at spare en enkelt rundtur
[09:28:29] <jonas@jones.dk> det hedder pubsubhubbub ;-)
[09:28:37] <jonas@jones.dk> det kan jeg godt
[09:29:05] <jonas@jones.dk> pubsubhubbub er ikke voldsomt kompliceret
[09:29:15] <[knud]> nej jeg sidder lige og læser på det
[09:29:31] <jonas@jones.dk> men det er "stopfodring" - som er mere tricky at håndtere end at trække det
[09:30:06] <jonas@jones.dk> der er færre libraries tilgængelige til at køre en pubsubhubbub end der er til at parse et Atom pull eller til at skrive AtomPub
[09:30:49] <[knud]> ok
[09:31:40] <stoejski> den der http ping indeholder den en direkte reference til indlæget?
[09:31:41] <[knud]> næste scenarie? - fra serveren?
[09:31:58] <jonas@jones.dk> jeg er ikke klar til at implementere en pubsubhubbub _server_ og de fleste ting der florerer er pubsubhubbub _klienter til at hægte sig på Googles server
[09:32:04] <jonas@jones.dk> ok
[09:32:32] <jonas@jones.dk> jeg ser to forskellige scenarier fra serveren:
[09:34:11] <jonas@jones.dk> a) der bedes om "status for bj934" som jeg allerede har liggende eller b) der bedes om "status for bj934 som er mindre end 15 minutter gammelt" eller "kommando til bj934" som jeg ikke har i forvejen
[09:34:37] <jonas@jones.dk> a) er at læse et blog-indlæg
[09:35:46] <jonas@jones.dk> b) er at skrive et blog-indlæg - som udlæser at min server sender sms til bilen og når der kommer svar - hvis der kommer svar - så opdateres samme indlæg med bilens respons
[09:35:47] <stoejski> altid c
[09:35:51] <jonas@jones.dk> ?
[09:36:15] <jonas@jones.dk> altid kommando? Aldrig status?
[09:36:16] <stoejski> nå a -> tredje
[09:36:38] <stoejski> altid kommando og altid hentet nyt fra bilen
[09:36:53] <jonas@jones.dk> dejligt at vide
[09:37:01] <stoejski> nå ja det er alt. b
[09:37:01] <jonas@jones.dk> så kan jeg godt skrotte mit system
[09:38:18] <jonas@jones.dk> Ingen grund til at bruge Atom protokollen hvis I altid vil have dugfriske data
[09:38:35] <[knud]> det vil vi gerne - jo nyere og hurtigere, jo bedre
[09:38:44] <jonas@jones.dk> hvem sagde hurtigere?
[09:38:57] <jonas@jones.dk> det bliver _langsommere_ af at droppe caching!
[09:39:05] <jonas@jones.dk> og mindre robust
[09:39:24] <jonas@jones.dk> World Wide Web er robust - men ikke "hurtigst"
[09:39:39] <[knud]> vi spørger kun bilerne om noget hvis der lige er sket noget ... eller den skal gøre noget før den rapporterer status
[09:40:14] <jonas@jones.dk> det tager ca. 10 sekunder for en telefon at ekspedere en sms
[09:40:31] <jonas@jones.dk> dvs. 10 sekunder for en round trip
[09:40:31] <[knud]> ja, det må vi jo leve med
[09:41:18] <jonas@jones.dk> kan det tænkes at I vil have behov for status for mere end een bil ad gangen?
[09:41:36] <stoejski> vi har ikke planer om masseudsendelser
[09:41:52] <[knud]> ikke i det nuværende setup
[09:42:35] <stoejski> i 95%+ af actions, er det brugeren som låser en bil op eller afleverer den
[09:43:41] <jonas@jones.dk> hvad så hvis I misser en besked? Så spørger I bare igen?
[09:43:57] <stoejski> yep
[09:44:18] <stoejski> det er brugeren som skla swipe med nøglebrikken igen
[09:45:00] <jonas@jones.dk> altså: ingen cahcing nogen steder - bare masser af sms'er altid, uanset at det er tidsmæssigt (og muligvis også økonomisk bekosteligt
[09:45:32] <stoejski> der er ikke nogen tilfælde hvor jeg kan se at vi kan bruge cache til meget
[09:45:48] <jonas@jones.dk> hvordan er det brugeren der skal swipe igen hvis det er jer der misser at modtage status om at bilen er blevet låst?
[09:46:12] <stoejski> bilen låser ikke af sig selv, det er serveren som låser bilen
[09:46:31] <stoejski> bilen gør intet uden at spørge serveren
[09:46:38] <jonas@jones.dk> prøv at fortælle mig en fuld gennemgang af en låsning af bilen
[09:46:53] <stoejski> brugeren kommer og vil bruge en bil: han swiper
[09:47:07] <stoejski> bj spørger hvitserk om det er okay
[09:47:57] <stoejski> hvis okay, sender hvitserk en besked til bilen om det , hvis det ikke er okay sender HS en besked at det ikker okay og bj blinker til brugeren med rød
[09:48:20] <stoejski> når bugeren er færdig, swiper han og venter til HS har låst bilen
[09:48:29] <stoejski> som så skal blinke til brugeren
[09:48:55] <jonas@jones.dk> ok
[09:49:20] <jonas@jones.dk> ...og HS stoler på at bilen har modtaget den sidste kommando om at låse?
[09:49:36] <jonas@jones.dk> blindt, mener jeg
[09:49:49] <stoejski> en sjældent gang(forhåbentlig) skal vagterne åbne eller låse bilen (igennem HS) eller endnu sjædelnere kan jeg gøre det direkte
[09:50:10] <stoejski> det er brugerens ansvar at bilen er låst
[09:51:07] <jonas@jones.dk> så brugeren står ude i kulden, swiper for at låse, og venter - rystende - de 20 sekunder det tager for et round trip
[09:51:58] <stoejski> yep
[09:52:07] <stoejski> det kan ikek være anderledes
[09:52:32] <jonas@jones.dk> det kan det godt, men ok
[09:52:54] <stoejski> nej, hvad hvis HS aldrig får fat på bilen fordi den står under et blytag?
[09:53:33] <stoejski> eller bilen ikke kan fortalle at den er låst
[09:54:10] <jonas@jones.dk> hvad gør brugeren så i en situation hvor bilen nægter at lade sig låse?
[09:54:24] <stoejski> hvsi der ikke er kommunikation skal brugeren bruge den rigtge nøgle og ringe til vagt
[09:55:09] <stoejski> vi kan ikke have at bilen låser (med den rigtig nøgle i handskerummet) og ikke kan låses op fordi kommunikation med HS ikke er muligt
[09:56:39] <jonas@jones.dk> ok
[09:59:12] <stoejski> udgangspunkt: bilen er dum og må/kan ikke gøre noget af sig selv
[09:59:34] <jonas@jones.dk> Al evt. caching ligger dermed i Hvitsærk. Ingen beskedhåndtering overhovedet - blot rå adgang.
[09:59:38] <stoejski> med undtagelse at sende en advarsel: fx batteriniveau kritisk
[09:59:47] <jonas@jones.dk> Så skal I ikke bruge AtomPub, men rå adgang til Kannel
[10:00:00] <stoejski> yep
[10:00:08] <jonas@jones.dk> http GET URLer á la denne: http://msg.delebilfonden.dk/sms?username=youneverknow&password=bbannent&to=%2B4542423461&text=Hej+%C3%A6n&from=%2B4540843136&coding=0&charset=UTF-8&smsc=J
[10:00:59] <[knud]> jeps, ser fint ud
[10:01:13] <[knud]> og tilsvarende den anden vej?
[10:01:18] <jonas@jones.dk> ...og så skal Hvitserk kunne _modtage_ tilsvarende URLer
[10:01:44] <[knud]> jo
[10:01:59] <jonas@jones.dk> Formatet er dokumenteret her: http://www.kannel.org/download/1.4.3/userguide-1.4.3/userguide.html#AEN2276
[10:02:34] <[knud]> fint - det kigger jeg på
[10:02:37] <jonas@jones.dk> Jeg brugere et Perl library til parsing af strengen - for erfaringsmæssigt kan der ske knas med bl.a. encoding af specielle tegn
[10:02:58] <jonas@jones.dk> men da det jo altid er bilerne i snakker med kan I måske slippe afsted med at håndkode parsing
[10:03:33] <jonas@jones.dk> jeg er *ikke* glad ved denne opsætning
[10:03:33] <[knud]> ja vi ved jo hvad bilerne kan finde på at sige
[10:03:42] <[knud]> hvorfor ikke?
[10:04:44] <jonas@jones.dk> jeg kan ikke sætte fingeren på det, men alt det knas jeg har haft det seneste år med sms til teaterprojekt har givet mig voldsom stor respekt for behovet for robust beskedhåndtering
[10:05:51] <stoejski> udover at brugeren skal vente er det vel rimelig robust
[10:06:06] <stoejski> og det er jo ikke ballet hvor timing spiller den store rolle
[10:06:11] <[knud]> jeg tror vi har en rimeligt robust håndtering  - vi har vagttelefonisterne som dem der kan "redde" systemet
[10:06:26] <jonas@jones.dk> Kan I huske hvordan der i '90-erne var en masse knas med at caching i web-browsere konstant drillede og skulle nulstilles?
[10:07:17] <jonas@jones.dk> oh, whatever
[10:07:18] <[knud]> ja tak
[10:07:29] <jonas@jones.dk> jeg er meget bekymret her
[10:07:50] <jonas@jones.dk> det er I ikke, og det er jer der står med lorten bagefter, så jeg prøver at ryste det af mig
[10:08:43] <stoejski> jeg forstår ikke helt hvor webbrowser kommer ind i billedet her
[10:09:16] <jonas@jones.dk> men jeg forventer at hvis det knirker og knager, så vil min reaktion være at hjælpe jer til at bruge en kommerciel udbyder (som er fucking ligeglade) fremfor at hjælpe med at lappe på systemet. For det er *fucking* stressende at lappe på et sms system når det er i produktion, skulle jeg hilse og sige - ballet eller ej!
[10:10:58] <stoejski> vi starter med 4 biler, worst case: vagten skal låse dem op og til med telefon
[10:11:26] <stoejski> det bliver i gennemsnit nok en 10-16 beskeder om dagen
[10:12:21] <jonas@jones.dk> parallel til web-browsere i '90-erne: At I ikke synes at caching er relevant, der skal altid leveres dugfriske data - er lissom tankegangen i '90-erne. Henover årtusindeskfitet blev der ryddet op i dårlig brug af web-protokollen, og idag bruges caching overalt!
[10:13:11] <jonas@jones.dk> Eksempel: Kannel er gammelt, og bruger web-protokol dårligt: Send et GET for at ændre data (sende en ny sms) - det er DÅRLIGT, der skulle bruges en POST til den slags
[10:14:00] <[knud]> enig - POST er det rette
[10:14:33] <stoejski> lad os tage et konkret eksempel (fordi jeg ikke er helt med med problemet)
[10:14:41] <jonas@jones.dk> Jeg vil gerne skåne jer for frustrationer á la '90-ernes web, og give jer en adgang til sms som er RESTful (som betyder "web-protokollen udnyttet sundt)
[10:14:46] <stoejski> brugeren står og vil lukke en bil op
[10:14:50] <jonas@jones.dk> stop
[10:14:52] <[knud]> men hvis Kannel ikke understøtter POST er det ok - Django kan sættes til at være transparent
[10:15:06] <jonas@jones.dk> det er ikke noget konkret jeg vil gøre anderledes, tror jeg
[10:15:15] <jonas@jones.dk> det er derfor jeg siger at jeg ikke kan sætte fingeren på det
[10:15:31] <jonas@jones.dk> det er den overordnede tankegang om at I altid vil have dugfriske data
[10:15:51] <jonas@jones.dk> du kan den dag idag deaktivere caching i din web-browser
[10:16:00] <jonas@jones.dk> ...men det går tæææææskelangsomt, så
[10:16:02] <stoejski> jeg kan bare ikke se at vi kan bruge "gamle" data til noget
[10:16:39] <stoejski> brugeren må ikke gå fra bilen og så lukker den pludslig op
[10:17:00] <jonas@jones.dk> så udtryk hvor gamle data må være, fremfor kategorisk at afvise at data har levetid
[10:17:39] <jonas@jones.dk> sms er ikke en synkron protokol
[10:18:01] <jonas@jones.dk> vi bliver nødt til, tror jeg, at anskue sms som asynkron
[10:18:16] <stoejski> det er derfor vi ikke vil have noget acknoledge
[10:19:51] <stoejski> og vi har kun en vejskommunication ad gangen
[10:20:13] <stoejski> brugeren prøver at åbne: BJ sender til HS
[10:20:39] <jonas@jones.dk> hvad så hvis en sms er 1.5 minut om at nå frem?
[10:20:48] <stoejski> han kan ikke sende igen før bj timer out
[10:20:57] <stoejski> lad os sige 25 sec
[10:21:18] <jonas@jones.dk> ikke forstået
[10:21:26] <stoejski> kommer der ikke svar til lige præcis den sms i løbet af 25 sec vil og må  BJ ikke åbne døren
[10:21:52] <stoejski> kommer der et svar fra HS skal døren åbnes
[10:22:27] <jonas@jones.dk> det forstår jeg ikke - hvordan sikrer BJ at det er den korrekte sms der responderes på?
[10:22:38] <stoejski> der står et løbenummer i sms
[10:23:16] <stoejski> og et timestamp
[10:23:18] <jonas@jones.dk> så HS sender ikke en "åbn bilen" kommando, men en "åbn bilen hvis denne kommando passer i serie"?
[10:23:57] <stoejski> åben bilen til åben-request nr#XXX
[10:25:45] <stoejski> går en af de to sms tabt eller er de forsinket vil der ikke ske noget andet at BJ tillader at brugeren må prøve igen
[10:27:31] stoejski leaves the room
[10:27:38] stoejski joins the room
[10:28:57] <stoejski> og så indbyger vi en time-stamp check sådan at selv brute-force åbninger af vagt eller mig ikke må være fosinket mere end 5 minutter
[10:30:14] <stoejski> kun sekventiel kommunikation med udløbsdatoer
[10:30:35] <stoejski> er du stadig meget urolig?
[10:31:37] <jonas@jones.dk> Jeg syntes dette var et spændende projekt. Nuer er jeg nervøs. Nej, jeg kan ikke argumentere for min nervøsitet, blot fortælle at den er der. Jeg har lyst til at hjælpe jer over til en kommerciel sms-udbyder fremfor at I/vi/jeg selv drifter det.
[10:32:48] <jonas@jones.dk> indtil da: forbind til min Kannel server direkte - som jeg beskrev lidt tidligere i snakken. Det vil ligne hvordan I senere skal snakke med kommercielle udbydere
[10:33:41] <jonas@jones.dk> Jeg vil lige få puttet et SSL certifikat på, så I kommunikerer krypteret til den, ellers er jeg klar.
[10:34:11] <jonas@jones.dk> jeg kan have det på plads i løbet af idag, regner jeg med.
[10:34:30] <jonas@jones.dk> Eller hvis det driller, så søndag aften (jeg skal til Århus i weekenden)
[10:34:40] <jonas@jones.dk> Æv.
[10:35:01] <stoejski> er det ikke det vi skal gøre tester med Kanel med din sms-gateway og hvsi du stadig er nervøs eller mener det er bedre med en com. sms udbyder så skifter vi til den (med din hjælp)
[10:36:48] <jonas@jones.dk> det var ikke min plan, nej. Min plan - indtil dette møde - var at HS skulle snakke robust med en AtomPub-til-Kannel gateway  som jeg har næsten færdig-udviklet og ville drifte på jeres server i Frankrig - og at den gateway så kunne flekse mellem at bruge min Kannel server her i Mørkøv eller en kommerciel udbyder.
[10:38:42] <jonas@jones.dk> Mit bud på plan nu er at HS snakker direkte med min Kannel server eller direkte med kommercielle udbyderes Kannel-agtige interfaces.  Og det første kun midlertidigt fordi jeg ikke tør at binde an med det :-(
[10:43:10] <stoejski> udelukker vores udgangspunkter egentlig hinanden?
[10:43:29] <stoejski> jeg må lige løbe og købe noget at spise
[10:57:02] <[knud]> jeg smutter nu ... vi snakkes ved
[10:57:08] <jonas@jones.dk> ok
[11:00:35] [knud] leaves the room
[11:12:40] <stoejski> i'm baackkk
[11:13:00] <jonas@jones.dk> med Schwarzenegger accent?
[11:13:33] <jonas@jones.dk> Kom han ikke også fra Østrig?
[11:13:43] <jonas@jones.dk> eller er det ikke dér du er fra?
[11:14:06] <stoejski> jo da vi er landsfæller
[11:14:21] <stoejski> men han kom vist fra linz
[11:14:43] <jonas@jones.dk> er det godt eller skidt?
[11:14:50] <jonas@jones.dk> altsp Linz?
[11:16:11] <jonas@jones.dk> Hvad mener du med om udgangspunkterne udelukker hinanden? At jeg kan give jer et RESTful interface som I så kan bypasse?
[11:16:55] <jonas@jones.dk> måske det giver mening.
[11:17:04] <stoejski> jeg er i bund og grund ligeglad hvordan de der sms'er kommer fra HS til BJ
[11:19:12] <jonas@jones.dk> da jeg kastede mig over teaterprojektet sidste år så jeg det som sms'er der skulle fra eet sted til et andet - og studsede over alle de mange paramtre der kunne tunes i Kannel
[11:20:06] <jonas@jones.dk> nu er jeg blevet klogere - jeg ved fortsat ikke hvad meningen med de fleste af paramtrene i Kannel er, men jeg forstår at de er væsentlige for robust håndtering af sms'er
[11:20:56] <jonas@jones.dk> ...og jeg kan se nogle svagheder ved at eksponere Kannels interface til eksterne services som ikke er tunet ind på netop Kannels måde at styre de parametre
[11:21:50] <jonas@jones.dk> Derfor har jeg prøvet at modellere en interface som er mere gængs og gennemtæsket i stor stil: distribution af blogs.
[11:22:39] <jonas@jones.dk> ...og så hægte Kannels tuningsfinnesser på dette interface efterhånden som jeg forstår dem og forstå hvordan de oversættes til Atom (dvs. blogging)
[11:22:58] <jonas@jones.dk> men hvis I ikke ser en fidus i det arbejde
[11:23:38] nagzilla leaves the room
[11:24:18] <jonas@jones.dk> så forventer jeg at evt. knas i mit arbejde af jer vil opleves frustrerende - som en unødig hæmsko
[11:24:41] <jonas@jones.dk> ...når I jo "bare" kan snakke direkte med Kannel i stedet
[11:26:35] <stoejski> jeg må indrømme jeg har ikke indblik i mekanimerne til at se poblemer eller fordele ved det ene eller andet
[11:28:30] <stoejski> jeg sover roligt over de procedyrer vi har på den yderste lag af dataudvekslingen: bj må ikke låse eller åbne uden at spørge HS, som skal svare i en bestemt tidsintervall
[11:28:57] <jonas@jones.dk> ja, det virker til at det er meget godt gennemtænkt
[11:28:58] <stoejski> forstår jeg det ikke rigtg at du er nervøs over "transport layer"
[11:29:31] <stoejski> der aner vi jo ikke meget, der kommer du som den erfarne i spillet
[11:30:23] <jonas@jones.dk> jeg er s'gu' usikker på om min "viden" er relevant, eller om det måske netop er fordi jeg i teaterprojektet _ikke_ havde ordentligt styr på det yderste lag
[11:30:37] <stoejski> hvis Knud får besked på hvordan han skal modtage eller sende sms'er, "burde" han også være ligeglad hvordan det sker i midten
[11:32:10] <jonas@jones.dk> jeg tror så meget på at der er behov for mere robust transport layer, at jeg selv i mit eget frivillige virke vil dedikere tid til at arbejde på det de næste mange måneder frem
[11:32:44] <jonas@jones.dk> men jeg er usikker på om det giver mening for jer at spilde krudt på at jeg arbejder på det til jeres brug
[11:32:54] <jonas@jones.dk> jeg tænker:
[11:33:06] <jonas@jones.dk> lige nu er det specifikt til at låse op og i
[11:33:20] <jonas@jones.dk> men jeg drømmer om flere brug - bl.a. live geo-location
[11:34:12] <stoejski> jeg værger mig som regel til at "overvåge" bilerne når de er i brug
[11:34:50] <jonas@jones.dk> brug med udgangspunkt i polling af "hvordan har bilen det" hvor det giver god mening at slække på "friskheden" af data
[11:35:12] <stoejski> bilerne er i ores varetagt når de holder på deres pladser (som er forhåbentlig statisk imellem brugernes brug)
[11:35:40] <jonas@jones.dk> det er en meget sund tilgang
[11:35:53] <jonas@jones.dk> men
[11:36:15] <jonas@jones.dk> jeg kan fint forestille mig etisk forsvarlige konstruktioner
[11:36:54] <jonas@jones.dk> eksempel: brugeren tilvælger egen geo-tracking
[11:37:06] <stoejski> der kommer så lidt dynamik i når en bruger kommer for sent, hvor man kunne bruge informationen af afstand til holdepladsen, eller efterspørgsel af biler, så man får rabat hvis man afleverer bilen der hvor der er brug for den
[11:37:20] <stoejski> en mere dynamisk model, hvor bilerne ikke har holdepladser
[11:37:27] <jonas@jones.dk> jeps
[11:38:42] <stoejski> men det bliver ikke aktuel før tidligst næste år. Så nu er det i 95% to sms'er vi skal kunne håndtere: bilen sender en sms og HS sender en sms
[11:39:03] <jonas@jones.dk> en bruger som tilvælger egen geo-tracking kan få rabat hvis der også tilvælges at geo-tracking deles med andre - altså så andre kan snappe en for tidligt afleveret bil mere effektivt fordi der varsles om at den er på vej hjem - automatisk fordi det kendes hvad "hjem" er og GPS rapporterer om hvor langt den er fra mål
[11:40:40] <jonas@jones.dk> jeg er skeptisk overfor at alt implementeres i eet monolitisk system (hvitsærk)
[11:41:07] <stoejski> lige nu arbejder jeg medt worst case scenarier (fordi vi har så relativ få biler af ens type ved de enkelte holdepladser). når bilen bevæger sig hjemad betyder jo ikke at han afleverer den , det kunne jo være at han har glemt konen ved holdepladsen ... ;-)
[11:42:04] <stoejski> jeg må desvære snart løbe
[11:42:32] <jonas@jones.dk> Hvis I kan se fidusen i - om et år - at bruge status om bilerne til flere formål end det helt snævre låse op låse i - så giver det mening for mig at vi bruger mit middle layer - selvom det ikke "udnyttes" i øjeblikket
[11:43:57] <jonas@jones.dk> jeg tror at jeg fortsat vil anbefale jer at bruge mit Atom mellemlag!
[11:44:15] <jonas@jones.dk> jeg vil anbefale jer at bruge mit Atom mellemlag!
[11:45:33] <jonas@jones.dk> Hvis I har brug for at Knud kan låse op og i mandag morgen, så kan jeg give midlertidig rå adgang til Kannel, men vil ellers forventeat være klar med mit Atom mellemlagi løbet af næste uge.
[11:46:19] <jonas@jones.dk> ...og vil derefter løbende udbygge mit mellemlag til bl.a. at kunne kooke på Jabber, som du har set tests af med Nagzilla
[11:47:27] <jonas@jones.dk> Hvis du - efter denne snak - synes at Atom mellemlaget virker som unødigt for jer, så sig til, så stopper jeg med at bruge tid på det (jeg vil fortsat udvikle på det men så meget langsommere, til eget hyggebrug)
[11:47:30] <stoejski> Knu dhar kigget lidt på det der Kannel og synes nok umiddelbar at det ser mest overkommelig ud, men hvis I kan finde ud af forklare hinanden hvordan HS sender og modtager SKAL han være mest interesseret i robust transport (han er nok bedøvende ... og  vil bare have et nemt IF)
[11:48:07] <jonas@jones.dk> jeg er slet ikke i tvivl om at han vil synes det er mest overkommeligt at sende en GET uanset hvad
[11:48:23] <stoejski> Jeg synes mest at navnet Atom og schwubtuwupsubhub lyder spændende
[11:48:37] <jonas@jones.dk> PUSH blandt venner
[11:49:11] <stoejski> betyder det noget for ham rent arbejdsmæssig om han skal GETe eller PUSHEe
[11:49:59] <jonas@jones.dk> han kan ikke teste POST eller PUT eller HEAD eller DELETE ved at skrive et i en webbrowser, kun GET
[11:50:55] <jonas@jones.dk> men i kode skulle det ikke være mere kompliceret - tværtom
[11:51:35] <stoejski> så kan jeg ikke se hvorfor vi ikke skulle gå din vej
[11:51:42] <jonas@jones.dk> ok
[11:51:44] <stoejski> vi skal ikke kunne oplukke mandag
[11:52:10] <stoejski> boksene kommer først i næste uge, tidligst onsdag/torsdag og så skal de indbygges
[11:52:43] <jonas@jones.dk> jeg vil prøve at kigge på måske at gøre det _endnu_ nemmere for ham - ved at give ham en protokol helt skrabet kun til BJ kommandoer, som ikke er pakket ind i AtomPub
[11:53:24] <stoejski> bj3 er online nu
[11:53:34] <jonas@jones.dk> så han blot skal skrive http://msg.delebilfonden.dk/jb/bilensnavn/kommando med POST
[11:53:37] <jonas@jones.dk> tak!
[11:53:44] <jonas@jones.dk> lad os slutte nu
[11:53:46] <stoejski> vi snakkes senere
[11:53:48] <jonas@jones.dk> jeps
[13:43:36] stoejski leaves the room
[21:43:15] jonas@jones.dk leaves the room
[21:43:15] Chatroom is destroyed
[21:43:15] Chatroom is stopped
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!