Netværkstransparens

I internetalderen er det yderst vigtigt at desktopprogrammer kan få adgang til ressourcer via internettet: De skal kunne hente filer fra en web-server, skrive filer til en FTP-server eller læse e-mail fra en e-mail-server. Ofte kaldes muligheden for at få adgang til filer uafhængig af deres sted for netværkstransparens.

Tidligere implementeredes forskellige måder at nå dette mål. Det gamle NFS-filsystem er et forsøg på at implementere netværkstransparens på POSIX-grænsefladesniveau. Mens dette fungerer rigtigt godt i lokale, tætkoblede netværk, skalerer det ikke for ressourcer med utilforladelig og muligvis langsom adgang. Her er asynkronisme vigtig. Mens du venter på at browseren skal hente en side, skal brugergrænsefladen ikke blokeres. Desuden skal sidefremvisningen ikke begynde når hele siden er tilgængelig, men den skal opdateres regelmæssigt mens data ankommer.

I KDE-bibliotekerne implementeres netværkstransparens med KIO-programmeringsgrænsefladen. Det centrale begreb i arkitekturen er et I/O-job. Et job kan kopiere filer, fjerne filer og lignende ting. Så snart et job er startet, arbejder det i baggrunden og blokerer ikke programmet. Al kommunikation fra jobbet tilbage til programmet, såsom at leverere data eller fremgangsinformation, gøres integreret i Qt's begivenhedsløkke.

Baggrundsoperationer opnås ved at starte I/O-slaver til at udføre visse opgaver. I/O-slaver startes som separate processer, og kommunikation sker via Unix domæneudtag. På denne måde behøves intet flertrådssystem, og ustabile slaver kan ikke få programmet som bruger dem til at bryde sammen.

Filsteder udtrykkes med URL'er som er omfattende brugt. Men i KDE, udvider URL'er ikke kun området med tilgængelige filer udenfor det lokale filsystem. De går også i modsat retning, f.eks. kan man søge i tar-arkiver. Dette opnås ved at indlejre URL'er i hinanden. En fil i et tar-arkiv på en HTTP-server ville kunne have URL'en:

http://www-com.physik.hu-berlin.de/~bernd/article.tgz#tar:/paper.tex

I de fleste tilfælde oprettes job ved at kalde funktioner i KIO-navnerummet. Disse funktioner har en eller to URL'er som argument, og muligvis også andre nødvendige parametre. Når jobbet er afsluttet, sender det signalet result(KIO::Job*). Efter signalet er sendets, fjerner jobbet sig selv. Derfor ser et typisk brugertilfælde sådan her ud:

void FooClass::makeDirectory()
{
    SimpleJob *job = KIO::mkdir(KURL("file:/home/bernd/kiodir"));
    connect( job, SIGNAL(result(KIO::Job*)), 
             this, SLOT(mkdirResult(KIO::Job*)) );
}

void FooClass::mkdirResult(KIO::Job *job)
{
    if (job->error())
        job->showErrorDialog();
    else
        cout << "mkdir gik godt" << endl;
}

Afhængig af jobtypen, kan du også forbinde til andre signaler.

Her er en oversigt over de mulige funktioner:

Begge jobbene KIO::stat() og KIO::listDir() returnerer deres resultater med typerne UDSEntry og UDSEntryList. Den sidste er defineret som QValueList<UDSEntry>. Forkortelsen UDS betyder "Universal directory service" (Generel mappetjeneste). Principperne bagved dette er at mappeindgangen kun indeholder information som en I/O-slave kan sørge for, ikke mere. For eksempel sørger HTTP-slaven ikke for nogen information om adgangsrettigheder eller ejere af filer. I stedet er en UDSEntry en liste med UDSAtoms. Hvert objekt sørger for en vis information. Den består af en type som opbevares i m_uds, og enten en heltalsværdi i m_long, eller en strengværdi i m_str, afhængig af typen.

Følgende typer er for øjeblikket definerede:

Selv om måden at opbevare information om filer i en UDSEntry er fleksibel og praktisk ud fra en I/O-slaves synvinkel, er det noget rod at bruge for den som skriver programmet. For eksempel for at finde ud af Mime-typen for filen, skal du løbe gennem hele indholdet og kontrollere om m_uds er UDS_MIME_TYPE. Heldigvis, er der en programmeringsgrænseflade som er meget nemmere at bruge: klassen KFileItem.

Ofte er KIO's asynkrone programmeringsgrænseflade for kompleks at bruge, og derfor er implementering af fuldstændig asynkronisme ikke en prioritet. I et program som for eksempel kun kan håndtere en dokumentfil af gangen, er der alligevel ikke meget som kan gøres mens programmet henter en fil. I disse enkle tilfælde, er der en meget nemmere programmeringsgrænseflade, i form af et antal statiske funktioner i KIO::NetAccess. For eksempel for at kopiere en fil, bruges:

KURL source, target;
source = ...;
target = ...
KIO::NetAccess::copy(source, target);

Funktionen returnerer efter hele kopieringsprocessen er afsluttet. Alligevel så sørger denne metode for en fremgangsdialog, og den sikrer at programmet behandler omtegningsbegivenheder.

En særlig interessant kombination af funktioner er download() sammen med removeTempFile(). Den første henter en fil fra en given URL, og gemmer den i en midlertidig fil med et entydigt navn. Navnet opbevares som det andet argument. Hvis URL'en er lokal, hentes filen ikke, men i stedet sættes det andet argument til det lokale filnavn. Funktionen removeTempFile() sletter filen som angives af argumentet, hvis filen blev oprettet af den foregående nedtegning. Hvis dette ikke er tilfældet, gør den ingenting. På den måde får man et meget enkelt kodefragment til at indlæse filer, uafhængig af deres sted:

KURL url;
url = ...;
QString tempFile;
if (KIO::NetAccess::download(url, tempFile) {
    // indlæse filen med navnet tempFile
    KIO::NetAccess::removeTempFile(tempFile);
}

Som det ses ovenfor, er grænsefladen for I/O-job ganske abstrakt og håndterer ikke nogen udbytning af information mellem programmer og I/O-slaver som er protokolspecifik. Det er ikke altid passendet. Man kan for eksempel give visse parametre til HTTP-slaven for at styre dens cacheopførsel eller sende en mængde cookies sammen med forespørgsler. Til dette behov er et begreb med metadata indført. Når et job oprettes, kan man indstille det ved at tilføje metadata til det. Hvert metadataobjekt består af et par med nøgle og værdi. For eksempel for at forhindre HTTP-slaven fra at hente en URL fra cachen, kan du bruge:

void FooClass::reloadPage()
{
    KURL url("http://www.kdevelop.org/index.html");
    KIO::TransferJob *job = KIO::get(url, true, false);
    job->addMetaData("cache", "reload");
    ...
}

Samme teknik bruges i den anden retning, dvs. til kommunikation fra slaven til programmet. Metoden Job::queryMetaData() spørger efter værdien af en vis nøgle som levereres af slaven. For HTTP-slaven, er et sådant eksempel nøglen "modified" (ændret), som indeholder datoen da URL'en sidst blev ændret (i form af en streng). Et eksempel på hvordan det kan bruges er følgende:

void FooClass::printModifiedDate()
{
    KURL url("http://developer.kde.org/documentation/kde2arch/index.html");
    KIO::TransferJob *job = KIO::get(url, true, false);
    connect( job, SIGNAL(result(KIO::Job*)),
             this, SLOT(transferResult(KIO::Job*)) );
}

void FooClass::transferResult(KIO::Job *job)
{
    QString mimetype;
    if (job->error())
        job->showErrorDialog();
    else {
        KIO::TransferJob *transferJob = (KIO::TransferJob*) job;
        QString modified = transferJob->queryMetaData("modified");
        cout << "Seneste ændring: " << modified << endl;
}

Når KIO-programmeringsgrænsefladen bruges, behøver du oftest ikke håndtere detaljerne med at starte I/O-slaver og kommunikere med dem. Det normale brugstilfælde er at starte et job med nogle parametre, og håndtere signalerne som jobbet sender.

Bagved scenen er scenariet meget mere kompliceret. Når du opretter et job, lægges det i en kø. Når programmet går tilbage til begivenhedsløkken, tildeles KIO slaveprocesser for jobbene i køen. For det første job som startes, er dette trivielt: en I/O-slave for en passende protokol startes. Efter jobbet (såsom en nedtagning fra en HTTP-server) er afsluttet, tages det dog ikke væk med det samme. I stedet tilføjes det til en gruppe med ledige slaver og fjernes efter en vis tid uden aktivitet (for øjeblikket tre minutter). Hvis en ny forespørgsel for samme værtsmaskine og protokol ankommer, genbruges slaven. Den åbenbare fordel er at ved en serie job med samme værtsmaskine, sparer man omkostningen ved at oprette nye processer, og muligvis også at gå gennem adgangskontrol.

Naturligvis er genbrug kun mulig når den eksisterende slave allerede har afsluttet sit tidligere job. Hvis en ny forespørgsel ankommer mens en eksisterende slaveproces stadigvæk kører, skal en ny proces startes og bruges. Med brugen i eksemplerne ovenfor af programmeringsgrænsefladen, er der ingen begrænsning på at oprette nye slaveprocesser: hvis man starter en serie nedtagninger af 20 forskellige filer i række, laver KIO 20 slaveprocesser. Dette system til at tildele slaver til job kaldes direkte. Det er ikke altid det mest passende system, eftersom det kan behøve meget hukommelse og give høj belastning både på klient- og servermaskine.

Så der er en anden måde. Man kan skemalægge job. Hvis man gør det, laves kun et begrænset antal (for øjeblikket tre) slaveprocesser for en protokol. Hvis du opretter flere job endnu det, så tilføjes de i en kø og behandles når en slaveprocess bliver ledig. Det gøres på følgende måde:

KURL url("http://developer.kde.org/documentation/kde2arch/index.html");
KIO::TransferJob *job = KIO::get(url, true, false);
KIO::Scheduler::scheduleJob(job);

En tredje mulighed er forbindelsesorienteret. For eksempel for IMAP-slaven, giver det ikke mening at starte flere processer for samme server. Kun en IMAP-forbindelse af gangen skal opretholdes. I dette tilfælde skal programmet udtrykkelig håndtere slavebegrebet. Det skal tildele en slave for en vis forbindelse og derefter tildele alle job som skal gå til samme forbindelse til samme slave. Dette kan igen nemt opnås ved at bruge KIO::Scheduler:

KURL baseUrl("imap://bernd@albert.physik.hu-berlin.de");
KIO::Slave *slave = KIO::Scheduler::getConnectedSlave(baseUrl);

KIO::TransferJob *job1 = KIO::get(KURL(baseUrl, "/INBOX;UID=79374"));
KIO::Scheduler::assignJobToSlave(slave, job1);

KIO::TransferJob *job2 = KIO::get(KURL(baseUrl, "/INBOX;UID=86793"));
KIO::Scheduler::assignJobToSlave(slave, job2);

...

KIO::Scheduler::disconnectSlave(slave);

Du kan kun afbryde slaven efter alle job som blev tildelt den er garanteret at være afsluttet.

I det følgende beskriver vi hvordan du kan tilføje en ny I/O-slave til systemet. På lignende måde som tjenester, annonceres I/O-slaver for systemet ved at installere en lille konfigurationsfil. Følgende fragment af Makefile.am installerer FTP-protokollen:

protocoldir = $(kde_servicesdir)
protocol_DATA = ftp.protocol
EXTRA_DIST = $(mime_DATA)

Indholdet i filen ftp.protocol er følgende:

[Protocol]
exec=kio_ftp
protocol=ftp
input=none
output=filesystem
listing=Name,Type,Size,Date,Access,Owner,Group,Link,
reading=true
writing=true
makedir=true
deleting=true
Icon=ftp

Indgangen "protocol" angiver hvilken protokol som slaven har ansvar for. "exec" er (i modsætning til hvad man naivt kan forvente sig) navnet på biblioteket som implementerer slaven. Når det er meningen at slaven skal starte, startes programmet "kdeinit", som derefter indlæser biblioteket i sit adresserum. I praksis kan du betragte slaven som kører som en separat proces, også selvom den er implementeret som et bibliotek. Fordelen ved denne mekanisme er at det sparer meget hukommelse, og reducerer tiden som behøves til linkning under kørsel.

Linjerne "input" og "output" bruges ikke for øjeblikket.

De tilbageværende linjer i filen .protocol angiver hvilke muligheder slaven har. Generelt er de funktioner som slaven skal implementere meget enklere end de funktioner som KIO-programmeringsgrænsefladen sørger for programmet. Grunden til dette er at komplekse job skemalægges som en følge af deljob. For eksempel for at få en liste over en mappe rekursivt, startes et job for topniveaumappen. For hver undermappe som rapporteres tilbage, startes nye underjob. Skemalægning i KIO sikrer at ikke for mange job er aktive samtidigt. På lignende måde, for at kopiere en fil med en protokol som ikke understøtter kopiering direkte (såsom FTP-protokollen), kan KIO læse kildefilen og derefter skrive data til målfilen. For at dette skal virke, skal .protocol annoncere handlingerne som slaven understøtter.

Eftersom slaver indlæses som delte biblioteker, men udgør fuldstændige programmer, ser deres kodeskelet noget anderledes ud sammenlignet med normale delte biblioteksindstiksprogrammer. Funktionen som kaldes for at starte slaven kaldes kdemain(). Denne funktion gør en del initieringer, og går derefter ind i en begivenhedsløkke og venter på forespørgsler fra programmet som bruger den. Dette ser ud som følger:

extern "C" { int kdemain(int argc, char **argv); }

int kdemain(int argc, char **argv)
{
    KLocale::setMainCatalogue("kdelibs");
    KInstance instance("kio_ftp");
    (void) KGlobal::locale();

    if (argc != 4) {
        fprintf(stderr, "Usage: kio_ftp protocol "
                        "domain-socket1 domain-socket2\n");
        exit(-1);
    }

    FtpSlave slave(argv[2], argv[3]);
    slave.dispatchLoop();
    return 0;
}

Slaver implementeres som delklasser til KIO::SlaveBase (FtpSlave i eksemplet ovenfor). På den måde svarer handlingerne i .protocol til visse virtuelle funktioner i KIO::SlaveBase som implementeringen af slaven skal omimplementere. Her er en liste med mulige handlinger og tilsvarende virtuelle funktioner:

Desuden er der funktioner som kan omimplementeres, og ikke er på listen i filen .protocol. For disse handlinger, afgør KIO automatisk om de understøttes eller ej (dvs. standardimplementationen returnerer en fejl).

Alle disse implementationer skal slutte af med et af to kald: Hvis handlingen lykkedes, skal de kalde finished(). Hvis en fejl opstod, skal de kalde error() med en fejlkode som første argument og en streng som andet. Mulige fejlkoder er på listen som nummereringstypen KIO::Error. Det andet argument er oftest URL'en det drejer sig om. Den bruges f.eks. i KIO::Job::showErrorDialog() for at parametrisere fejlmeddelelsen som er læsbart af brugeren.

For slaver som svarer til netværksprotokoller, kan det være interessant at omimplementere metoden SlaveBase::setHost(). Den kaldes for at fortælle slaveprocessen om værtsmaskine og port, og brugernavn og kodeord der skal bruges for at logge på. Generelt kan metadata som angives af programmet hentes med SlaveBase::metaData(). Du kan kontrollere om metadata med en vis nøgle findes med SlaveBase::hasMetaData().

Diverse handlinger som implementeres i en slave, behøver en måde at sende data tilbage til programmet som bruger slaveprocessen.

Ind imellem skal en slave kommunikere med brugeren. Eksempler kan være informative meddelelser, dialoger til godkendelseskontrol og bekræftelsesdialoger når en fil er ved at blive overskrevet.