Flytting av http://rel.kxml.no/noark5/

[henningjensen]

Løsningen bør flyttes til arkivverkets domene. I tillegg bør formen på den revurderes, da den er fryktelig tung å vedlikeholde.

[henningjensen]

Oppgaven innebærer:

• Arkivverket må opprette nytt subdomene, rel.arkivverket.no
• Nytt subdomene dirigeres til dagens rel.kxml.no
• Alle lenker i standarden må endres til rel.arkivvkerket.no
• Alle lenker i eksempelapplikasjonen må endres til rel.arkivverket.no

[petterreinholdtsen]

[Henning Jensen]

Oppgaven innebærer: * Arkivverket må opprette nytt subdomene, rel.arkivverket.no * Nytt subdomene dirigeres til dagens rel.kxml.no * Alle lenker i standarden må endres til rel.arkivvkerket.no * Alle lenker i eksempelapplikasjonen må endres til rel.arkivverket.no

Endring av alle lenker i standarden gjør at alle implementasjoner av standarden må endres, både tjener og klient. I tillegg lager det et vannskille der klienter som ser etter rel.kxml.no ikke fungeer med tjenermaskiner som bruker rel.arkivverket.no, og klienter som ser etter rel.arkivverket.no ikke fungerer med tjenermaskiner som bruker rel.kxml.no Det er vel mindre jobb totalt sett å endre eierskap på kxml.no til arkivverket, og la standardteksten være uendret? Eierskapsbytte innebærer disse oppgavene * Dagens eier ber om eierbytte hos sin DNS-registrar * Ny eier aksepterer eierbytte hos sin DNS-registrar

…

-- Vennlig hlisen Petter Reinholdtsen

[henningjensen]

Det er strengt tatt KS som burde eie det domenet, da de har mest informasjon der.

Vi bytter lenke nå fordi det blir første offisielle versjon. Versjonen som hittil er utgitt er en beta versjon. Vi må kunne gjøre slike endringer selv om det vil få konsekvenser for noen systemer.

[petterreinholdtsen]

En må la være å gjøre slike endringer hvis spesifikasjonen skal få noen utbredelse, da ustabile standarder er lite populære å forholde seg til. Er det noen måte dette kan gjøres på en bakoverkompatibel måte? En måte er vel at alle API-tjenere i en overgangsfase tilbyr alle lenker dobbelt opp, med både gammel og ny relasjon. Da vil klienter som bruker både gammel og ny relasjon finne det de ser etter. Kan det være en løsning her? Eventuelt så kan klienter oppgi en API-versjon, og tjeneren dele ut gamle eller nye relasjoner alt etter hvilken versjon klienten oppgir å bruke.

Når det er sagt, så er det helt klart billigere å gjøre en slik endring tidlig, selv om det billigste er å ikke gjøre endringen overhodet.

[AnnKnu]

Denne må avklares intern i Arkivverket. Settes på hold til den er avklart.

[hanber]

Det er vel også et spørsmål om hvor mange som i det hele tatt har tatt i bruk beta-versjonen. Hvis det er Evry og OsloMets (nikita) er det kanskje overkommelig.

[petterreinholdtsen]

[Hans Fredrik Berg]

Det er vel også et spørsmål om hvor mange som i det hele tatt har tatt i bruk beta-versjonen. Hvis det er Evry og OsloMets (nikita) er det kanskje overkommelig.

Ja, det var det jeg mente med at det er billigere jo tidligere en slik endrings gjennomføres. Men en slik endring gir opplevd stabilitet et solid skudd for baugen hvis så fundamentale deler av spesifikasjonen endres mellom versjoner uten at def finnes en plan for bakoverkompabilitet, og dermed i praksis straffer de som har vært tidlig ute. Jeg håper derfor dere kan finne en løsning som ikke gjør alle eksisterende implementasjoner i strid med neste versjon av API-spesifikasjonen. Hva med å høre med KS om Arkivverket kan ta over eierskap til DNS-navnet, mens dagens bruk forblir som i dag? Da er en beskyttet mot konkurs, uten at det trengs noen endring i hverken spesifikasjon eller annen bruk av rel.kxml.no.

…

-- Vennlig hilsen Petter Reinholdtsen

[AnnKnu]

Arkivverket må opprette nytt subdomene, rel.arkivverket.no og nytt subdomene dirigeres til dagens rel.kxml.no

[henningjensen]

Arkivverket må sette opp CNAME for rel.arkivverket.no som peker til rel.kxml.no

[petterreinholdtsen]

Det som skrives gir inntrykk av at planen er å bytte alle rel-lenker i spesifikasjonen. Hva er planen for bakoverkompatibilitet for klienter og tjenere som i dag bruker relasjonsnavnene som inneholder rel.kxml.no? En CNAME vil jo ikke påvirke hva klienter ser etter av relasjonsnavn, og heller hva en tjenermaskin deler ut av relasjonsnavn.

[petterreinholdtsen]

En ide som kanskje kan hjelpe både i denne utfordringen og i overgangen til n5v5 (#71), er å introdusere støtte for alias-relasjoner i _links, slik at en operasjon kan ha flere relasjonslenker. Det kan for eksempel formatteres slik:

{
  "_links": [
    {
      "rel": "http://rel.kxml.no/noark5/v4/api/arkivstruktur/mappe",
      "relalias": ["http://rel.arkivverket.no/noark5/v4/api/arkivstruktur/mappe"],
      "href": "somewhere"
    },
    ...
  ]
}

Etter hvert kan dette så snus til å ha de opprinnelige relasjonsnavnene som alias, og de nye som primærnavn:

{
  "_links": [
    {
      "rel": "http://rel.arkivverket.no/noark5/v4/api/arkivstruktur/mappe",
      "relalias": ["http://rel.kxml.no/noark5/v4/api/arkivstruktur/mappe"],
      "href": "somewhere"
    },
    ...
  ]
}

Foreslår her at attributten relalias peker til en lenke med alternative navn for samme operasjon/relasjon, slik at en kan håndtere flere overganger i samme API.

[petterreinholdtsen]

Det kan se ut til at de eneste API-klientene som er skrevet så langt er de klientene jeg har skrevet for å teste Nikita-prosjektet, samt de som brukes internt i Nikita-prosjektet. HK-data forteller at ikke har skrevet klientkode så langt, og API-et som Evry har laget følger ikke strukturen til denne spesifikasjonen og må dermed uansett skrives om til å bli i tråd med tjenestegrensesnittet. Dermed er det i realiteten kun to Nikita-prosjektet som blir direkte påvirket når relasjonsnøkkelnavnene endres.

[tsodring]

Angående denne. nikita har oppdatert til rel.arkivverket.no

[petterreinholdtsen]

Jeg gikk ut i fra at den nye URL-en vil bruke https, men ser at endringsforslaget fra @anastasiyaArk bruker http. Nettlesere advarer mot nettsider uten https, og bruken av ukrypterte forbindelser gjør det enklere for uhederlige aktører på nettet å bytte ut informasjon fra nettsiden under overføring. Dette og mere til gjør at jeg anbefaler på det sterkeste å bytte fra http: til https: i relasjonsnøkkelnavnene.

[henningjensen]

Det er en glipp, vi skal selvsagt over på https.