Lurer du på hvordan Twitter virker? På min norske twitter-konto (@sjetilv) følger jeg en del ikke-tekniske landsmenn, og jeg har begynt å mistenke at ikke alle helt vet hvordan det hele snurrer rundt.

Det begynte med at jeg postet en tweet med stavefeil i, og så la ut følgende lille sukk:

Det evige Twitter-dilemma: La den dumme tastefeilen leve, eller risikere enda dummere nesten-identiske meldinger i folks klienter?

Straks fikk jeg et spørsmål: Hva i all verden var det jeg mente nå? Noen av dere har kanskje sett dette fenomenet i Twitter-klientene deres: Noen har postet to meldinger som ser nesten helt like ut. Den første har typisk en skrivefeil som er rettet opp i den andre, og det hele ser litt dumt ut. Han som lurte hadde imidlertid ikke sett dette, og skjønte ikke hva jeg snakket om.

Denne problemstillingen er helt åpenbar for oss nerder, og noe jeg bare kan nevne i forbifarten til en annen programmerer, og hun vil bare nikke og himle litt med øya. Men ikke han her karen. Etter noen forsøk på utdypinger gikk det opp for meg at ikke alle vet hvordan Twitter egentlig virker. Så her følger et forsøk på å forklare for ikke-tekniske følgere – litteraturleverandører, litteraturkritikere, litteraturkritikerkommentatorer, litteraturforskere, litteraturkritikkforskere, politikere, kommentatorer av politikere, generelle mediefolk og evt. andre avskygninger av ikke-tekniker  – hvordan Twitter virker. Jeg skal gjøre et ærlig forsøk på å holde det menneske-lesbart, uten å forenkle altfor mye.

«Menneske-lesbart» betyr forresten «kan leses av mennesker» i fagsjargongen. Dere som er litt nervøse for IT-eksperter, kan kanskje finne det betryggende at vi har et ord for det.

Først setter vi ting i bås: Twitter er en såkalt klient-tjener-arkitektur. Modellen er enkel og hele webben er ett stort eksempel: Noen få store maskiner fungerer som tjenere (eller servere), og mange små maskiner er klienter. For eksempel: Adressen vg.com peker på en tjener, og klienten er maskinen du kjører webleser på. Det er såklart mange slike tjenere, men likevel mange flere klienter. Ideen er forøvrig en del eldre enn webben.

Vi kan se på Twitter som tjeneren/serveren i denne diskusjonen. Klienten er programmet du kjører på maskina di, som f.eks. Tweetie, Tweetdeck eller Echofon. Dette er helt analogt med hvordan weblesere – altså Firefox, Safari… den andre – forholder seg til en webtjener. Webleseren og Twitter-klienten er som fremvisningsmotorer, men innholdet serveres av – ta da – serveren. For webleserens del er dette innholdet på formen HTML (Hyper-Text Markup Language), som er en variant av språket XML (eXtensible Markup Language).

Twitter-klientene, derimot, spiser ren XML. Mer om dette senere, på dypere vann.

Først må vi nemlig introdusere begrepet protokoll. (Iallefall er det veldig fristende.) En protokoll er simpelthen en overenskomst mellom partene – dvs. tjener og klient i vårt tifelle – om hvordan kommunikasjonen skal foregå. HTTP er en slik protokoll (Hyper-Text Transfer Protocol), og alle websider leveres faktisk over denne protokollen. Og det stopper ikke der: Man kan bygge nye protokoller på toppen av gamle, og noen har altså fått det for seg å lage noe som heter REST (Representational State Transfer) oppå HTTP igjen. Protokollen er en enighet mellom avsender og mottager om det grunnleggende for kommunikasjonen.

Skal du oppnå litt status hos en nerd, f.eks. hvis du trenger noen til å fikse Outlooken din, så kan det lønne seg å snike inn ordet «protokoll» i samtalen. Det er et generelt tips. Og apropos gamle ideer; hypertekst er en eldgammel ide som stammer fra rundtomkring krigens dager. Les mer her.

Men hvorfor gjøre dette vanskeligere enn det er, spør du kanskje. Hvorfor REST oppå HTTP? Da skal du vite at REST er en forenkling av noe forferdelige greier som heter SOAP (Simple Object Access Protocol). Folk som har vært utsatt for denne teknologien kan fortelle deg at ikke er mye som er «Simple» med det, men da SOAP ble introdusert var det faktisk et radikalt forenklet alternativ til datidens svarte magi, som stammens eldste kalte Corba (Common Object Request Broker Architecture), som skulle være en felles basis mellom leverandører. Folk som har slitt med det kan fortelle at det ikke var så mye som var «common» her heller. Denne bransjen har mye tapt tid å svare for.

Men hensikten med alle disse forkortelsen er aktverdig nok: å bli enige om hvordan datamaskinene skal snakke sammen, og bli enige om noe som er enkelt nok til å bli alment akseptert. Einsteins ord gjelder her – as simple as possible, but no simpler – for da virker det ikke. Det mest vellykkede eksemplet er internett, som er mulig pga. en pen stabel av slike protokoller. Ganske langt nede i denne stabelen finner du UDP og TCP, og litt nedenfor der snakker vi om transistorer, strøm, spenning og lysfotoner. Disse teknologiene stammer for det meste fra det amerikansk forsvaret, og fra amerikanske universiteter. Så å stable REST oppå HTTP er verken særlig originalt eller uansvarlig.

Uansett, REST gjør at du kan gjøre en forespørsel til en server over HTTP. Det betyr at du kan gjøre dem fra browseren din – noe vi skal gjøre straks – og få et svar tilbake som du kan kikke på, selv om det egentlig er beregnet på andre programmer enn weblesere -programmer som Twitter-klienter. De snakker nemlig også HTTP, men på en RESTful (fint ord) måte, oppå HTTP. Svarene de får er ikke i språket HTML, men XML. Dette kan vi se selv, og uten at noen kan beskylde oss for hacking. Denne linken vil du klikke på: (NB: åpner nytt vindu)

http://twitter.com/statuses/user_timeline.xml?screen_name=sjetilv

Tips: Firefox er mest hensiktsmessig å leke mer her. Hvis du bruker Safari, får du opp en fryktinngytende murstein med tall og tekst. Velg «View Source» fra View-menyen for å se strukturen – strukturen som Firefox-brukere får opp med en gang. Sist jeg brukte IE, hadde den noe som lignet på Firefox-opplegget, så jeg tror de greier seg.

Hvis du har et vindu oppe nå, skjønner du at dette er den typen ting som får journalister til å gripe etter pennen og notere seg for en bildetekst av sorten «helt uforståelig for folk flest». Men pust dypt og rolig og se nøyere på den. Øverst i denne strukturen et sted skal det stå <statuses>. Dette er altså et XML som beskriver statuser, dvs. det vi som regel kaller meldinger.

XML skal være «menneske-lesbart» – for å repetere, så er betyr det altså «skal kunne leses av mennesker» – iallefall ifølge de som laget XML. De som laget XML er, ifølge atter andre, en flokk bavianer. XML er en suksess i bransjen – det er fleksibelt og allsidig, og alle kan bruke det til alt mulig rart. Problemet med slike teknologier er nettopp at alle bruker det til alt mulig rart. Ganske snart vil ganske mange folk lage ganske dumme ting som du må forholde deg til, og det hele blir et lite mareritt. Man skulle kanskje tro at slikt ville gi litt status – å komme opp med noe som er allsidig og brukt av mange – men nei: Det er faktisk den sikreste måten å bli lagt for evig hat av et stadig voksende antall mennesker, helt til noen kommer opp med noe nytt. Dette nye ser i starten så mye enklere og greiere ut, noe som gjør at det blir brukt til stadig mer av stadig flere… og historien gjentar seg.

XML er for tiden det som alle hater, og det som alle bruker. Det gjør det ikke mindre frustrerende at XML ble designet av en komite, så ansvaret er pulverisert. Men, i Twitters tilfelle er heldigvis bruken av XML nokså streit og edruelig. (Dessuten kan du bruke JSON istedet, som er under oppseiling som alment hatobjekt, men det tar vi ikke her.)

Nedenfor følger en full beskrivelse, på XML-form, av en Twitter-melding – en status, som det av historiske årsaker heter. I XML er det en <status> – ja, du kan si status inni statuses og derfor kaller de det menneske-lesbart, så dumt er det faktisk. Men den beskriver iallefall meldingen som jeg nevnte i starten. Dette er ikke feik, dette er nøyaktig det serverne til Twitter vet om meldingen min:

<status>
  <created_at>Sun Nov 01 11:16:58 +0000 2009</created_at>
  <id>5335664765</id>
  <text>
    Det evige Twitter-dilemma: La den dumme 
    tastefeilen leve, eller risikere enda 
    dummere -identiske meldinger i folks 
    klienter?
  </text>
  <source>
    <a href="http://echofon.com/" rel="nofollow">Echofon</a>
  </source>
  <truncated>false</truncated>
  <in_reply_to_status_id/>
  <in_reply_to_user_id/>
  <favorited>false</favorited>
  <in_reply_to_screen_name/>
  <user>
    <id>55487753</id>
    <name>Sjetil Vahlstaved</name>
    <screen_name>sjetilv</screen_name>
    <location>iPhone: 59.918884,10.757684</location>
    <description>
      Velintegrert innvandrer i Oslo, men 
      med et navn som tydeligvis ikke lar
      seg uttale sør for Stadt. Norwegian
      whining only, for tech stuff please
      see @kjetilv.
    </description>
    <profile_image_url>
      
    </profile_image_url>
    <url>http://twitter.com/kjetilv</url>
    <protected>false</protected>
    <followers_count>184</followers_count>
    <profile_background_color>9AE4E8</profile_background_color>
    <profile_text_color>333333</profile_text_color>
    <profile_link_color>0084B4</profile_link_color>
    <profile_sidebar_fill_color>DDFFCC</profile_sidebar_fill_color>
    <profile_sidebar_border_color>BDDCAD</profile_sidebar_border_color>
    <friends_count>238</friends_count>
    <created_at>Fri Jul 10 06:08:44 +0000 2009</created_at>
    <favourites_count>5</favourites_count>
    <utc_offset>3600</utc_offset>
    <time_zone>Prague</time_zone>
    <profile_background_image_url>
      
    </profile_background_image_url>
    <profile_background_tile>false</profile_background_tile>
    <statuses_count>1124</statuses_count>
    <notifications>false</notifications>
    <geo_enabled>false</geo_enabled>
    <verified>false</verified>
    <following>true</following>
  </user>
  <geo/>
</status>

Dette kan se litt apokalyptisk ut, men egentlig er det bare meldingen min, inni <text>-taggen, i tillegg til data om kontoen min, bl.a. bioen min, en peker til profilbildet, fargevalg på profilsiden min (!) og en peker til bakgrunnsbildet mitt.

Dette er – bokstav for bokstav – de dataene som Twitter-klientene våre har å leke med. En svært interessant bit er feltene som begynner med in_reply_to. De er tomme i statusen over, men i andre meldinger kan de se slik ut:

<in_reply_to_status_id>
  5344302505
</in_reply_to_status_id>

<in_reply_to_user_id>
  17066475
</in_reply_to_user_id>

Dette er måten Twitter holder styr på hvem som har svart til hvem. Klientene kan gjøre mange forskjellige slags kall, blant annet kan de be om enkelt-statuser, f.eks. melding 5344302505. Når du ber Twitter-klienten din om å liste opp en lengre samtale, kan den gjøre det ved å følge tråden bakover på denne måten – melding X er et svar på melding Y, så da henter vi Y, og hvis den er et svar på melding Z, henter vi Z, osv.

Du kan i teorien lage en Twitter-klient som gjør dette oppslaget på alle du følger, men det ville vært urimelig tregt å spørre Twitter en gang for hver. For å gjøre det mer effektivt, er det lagt opp til at dette håndteres sentralt på serversiden, og at klientene kan be om et sammendrag slik:

http://twitter.com/statuses/friends_timeline.xml

Åpner du denne linken, skal browseren din be deg om å logge inn, og da kan du taste inn vanlig Twitter-brukernavn og passord. Hvis du ikke stoler på bloggen min, kan du logge deg inn på Twitter som vanlig først, og trykke på linken etterpå. I retur vil du få de 20 siste tweetsene som din konto skal se. Med litt fikling kan du variere hvor mange du vil se, om du vil se alle som har kommet siden et visst tidspunkt osv. Men poenget er at denne listen lages for deg på serveren, slik at klienten kan hente den i ett jafs.

Så for å spinne oss tilbake til utgangspunktet: Hvordan forklarer dette at noen klienter viser både den gamle og den nye meldingen, når jeg sletter den gamle og poster på nytt? Årsaken er at klienten som regel tar vare på informasjon den har fått fra tjeneren. Hvis den skulle hente alle meldingene hver gang den refreshet, ville bli treg i bruk og kjapt byttet ut med en annen klient. Dermed kan følgende skje:

  1. Jeg poster en melding med skrivefeil
  2. Klientene til (noen av) mine følgere spør om lister over nye meldinger, inkludert min tabbemelding. Dette gjør de ikke for å være ekle med meg, det er bare noe de gjør med jevne mellomrom. De tar vare på disse meldingene på maskinene de kjører på, og viser dem frem til brukerne sine.
  3. Jeg banner og sverter, sletter den gamle meldingen min og poster en ny.
  4. De klientene som fikk den første meldingen spør etterhvert om nye lister, og får lister som inneholder den nye meldingen, men ikke den gamle.

Og her oppstår noen ganger det fenomenet at begge meldingene vises. Hvorfor? Rett og slett dårlig bokholderi fra klientens side. Typisk tar den de nye tweetsene og lister dem opp som den skal, men glemmer at ting som ikke er listet opp lenger må fjernes fra de listene den har lastet ned før. Som vi sier: FAIL!

Så for å samle trådene: Twitter og klientene snakker sammen med HTTP-kall og XML (evt. med alternativer til XML som bare er andre måter å si de samme tingene på), og mer er det egentlig ikke å si om den saken. Twitter tilbyr et offisielt API – et Application Programming Interface på fint – altså et grensesnitt for å programmere applikasjoner – applikasjoner som Echofon, TweetDeck osv. Grensesnittet er fullt ut beskrevet her:

http://apiwiki.twitter.com/Twitter-API-Documentation

Med det som står på denne siden kan du egentlig sette igang og lage din egen Twitter-klient. Prøv gjerne ut noen kall i browsere din, og se på resultatet. Vær snill og følg deres Terms of Service. Du kan ikke bruke det du har lært her til spamming. Hvis du blir for ivrig, rammes du av rate limiting, som er på 150 kall i timen. Når klienten din stopper opp nå og da, kan det være fordi den har gjort for mange forespørsler i det siste, f.eks. hvis du har listet opp mange konversasjoner.

Utviklere trenger ikke mer for å lage en skikkelig kul Twitter-app, og antagelig er dette en av driverne for populariteten. Her kan du også se om Twitter tilbyr noen kule funksjoner som klienten din ikke bruker ennå – f.eks. er report spam sikkert en fremtidig slager. Vi kan også se at de planlegger støtte for retweets (RT) – dette blir mest sannsynlig innslag i XML’en som peker på den retweetede meldingen. Idag kan man bare peke på meldingen som er besvart.

Noen andre festlige ting som klienter ikke gjør så ofte:

Oss teknikere imellom: I bransjen har Twitter fått en anelse taperstempel å stri med, og det er ikke pga. misunnelse over suksessen. Teknologibransjen er meritokratisk: de som kan vise til merittene er de som rår. De sliter rett og slett litt fordi teknologien er haltende. Twitter er som kjent stadig nede, og det er mye pga. problemer internt, som skyldes tekniske veivalg som helt klart er svake, noen vil si stupide. Noe av dette er det forståelige historiske årsaker til, f.eks. at tjenesten opprinnelig ikke ble laget med noen stor brukerbase i tankene.

Twitter er på en måte det alle bruker, og det alle hater – iallefall litt; begrensningen på 140 tegn f.eks. – akkurat som XML. Det er et bra sted å være i en tid, men det betyr at det må komme noe nytt – noe som er mye enklere og greiere, og som alle kan bruke til alt mulig rart … dette er kreativ ødeleggelse satt i system, bortsett fra at det ikke er i system, det er mer et slags markedsdrevet, ustabilt økosystem av teknologi, ideer, gjennomføringsevne. Kreftenes frie spill, vil noen si, med mer eller mindre skrekkblandet fryd. Og det er egentlig den beste grunnen til å drive med data og sånn.

Reklamer



Kategorier