Õnnestus VirtualBox abil saada tööle vana hea DOS 5.0 ja Turbo Pascal. Kuna 5.5 veel hiirt ei toetanud ning oli üleüldse kohmakas (puudus “graafiline” failivaliku aken jne), siis installeerisin ka versiooni 7.1.

Kahjuks aga on endiselt probleemid CRT mooduliga, minu teada mingit väga head lahendust selle vastu ei olnud. On küll mingi patcher mis .EXE failid üle tõmbab, aga drop-in lahendust, kus saaks mooduli CRT asendada näiteks mooduliga CRT2 ma ei suutnud hetkel tuvastada. Mälu järgi nagu midagi oleks siiski olnud, ei tule lihtsalt meelde.
Kuidas saada teada, millisele objektile viitab this vaikimisi kui tegu on objekti meetodiga? call, apply ja bind abil saab seda ka ise muuta, kuid mis on selleks vaikimisi?
Rusikareegel on, et tuleb vaadata funktsiooni käivitamise hetkel (st. sellel kohal, kus funktsiooniväärtuse taga on sulud) käivitatava väärtuse vasakut poolt - misiganes sealt vastu ei vaataks, see ongi kontekst.
Math.round(); // meetodi *round* kontekst on *Math*
window.Math.round(); // kontekst on *window.Math*
Juhul kui seal pole midagi, on kontekstiks window.
alert(); // funktsiooni *alert* kontekst on *window*
Kui tegu on callback funktsiooniga, siis on kõik sama - arvestada ei tule mitte selle seadmise hetke, vaid käivitamise hetke
function foo(callback){
callback(); // <-- siin toimub käivitamine
}
foo(console.log); // <-- siin seadmine
Näites ei ole käivitatava meetodi log kontekstiks mitte console vaid window! Kuna konteksti seab käivitamise hetk ning lause callback(); juures, erinevalt lausest foo(console.log) enam konteksti määratud pole - vasakul pool kävitatavat väärtust pole märgitud midagi.
Et mitte jätta konteksti juhuse hooleks tasub tagasikutsefunktsioonide juures kasutada väärtuse seadmise hetkel meetodid bind (ES5 lisa, töötab vaid moodsaimates brauserites, samuti ka NodeJS platvormil) või käivitamise hetkel meetodeid call või apply.
// tagasikutsefunktsiooni kontekstiks saab *console*
foo(console.log.bind(console));
või
// käivitatava funktsiooniväärtuse kontekst on *console*
function foo(callback){
callback.call(console);
}
Täpsustuseks märgiks veel ära, et kirjeldatud kontekst this olulisus seisneb selles, et kontekst viitab “iseendale”. See tähendab, et objekti meetodi sees saab kasutada objekti muid omadusi ja meetodeid, ilma et oleks vaja teada objekti nimetust vms viidet.
foo = {
bar: 1,
foobar: function(){
alert(this.bar); // <-- kontekstiks on objekt *foo*
// *this.bar* on sama mis *foo.bar*, kuid konteksti
// tõttu pole vaja *foo* nime teada
}
}
NB! Kui tagasikutse funktsioonile on meetodiga bind kord juba kontekst seatud, siis seda call või apply abile muuta enam ei saa.
function bar(){
alert(this.baz);
}
function foo(callback){
callback.call({baz:1}); // <-- ei muuda enam midagi
}
foo(bar.bind({baz:2}); // <-- bind seab konteksti
Eelmises postituses mainisin, et minu matemaatiliste valemite rakendust on praeguseks alla laetud 1000 korda, siinkohal siis valgustaks veidi tagamaid.
Ma ei teinud seda rakendust erilise eesmärgiga, soov oli vaid proovida läbi kogu töövoog alates sellest et on idee, kuni selleni, et rakendust saab AppStorest alla laadida. Idee teket täpselt ei mäleta, igatahes sai selleks matemaatika valemite kuvamine - sisuliselt on tegu spikriga, valid teema ning näed vastavaid valemeid (nt. ruutvõrrandi valemit). Kuna eeldatav sihtrühm krediitkaarti ei oma (tegu siiski kooliõpilastega), siis oli plaaniks teha rakendus tasuta ja selle eest mitte raha küsida.
C keeles ma suurt ei orienteeru, viimased katsetused jäid aastate taha kui tegin TTÜ’s mingeid kodutöid, seega sellele väga keskenduda ei tahtnud. Õnneks on praeguseks saada ka erinevaid toolkit‘e, mis võimaldavad mugavamalt hakkama saada. Minu esimeseks valikuks sai PhoneGap, mis on sisuliselt UIWebView wrapper. Teed HTML lehe, paned selle JavaScriptiga “elama” ja pakid rakenduseks kokku.
Twitterist sain vihje, et on olemas ka parem süsteem nimega Appcelerator, mis sisuliselt on sama, aga ainult UIWebView asemel pakub ehitusklotsidena kõiki native UI elemente ning selmet veebilehena asja kuvada, kompileerib eraldiseisvas failis oleva JavaScripti koodi iPhonele arusaadavaks - ühesõnaga veebilehe asemel kompileeritakse programm native app‘iks.
Rakenduse struktuur on väga lihtne. Põhivaade koosneb kahe elemendiga TabGroup objektist. Esimene element sisaldab “sisukorda”, teine valitud teema valemeid.
Sisukorravaade koosneb TableView elemendist, mille sees on üksikud TableViewRow elemendid. Kusjuures, igale reale on seatud eraldi “onclick” kuular, nii et kui mõnel real vajutada, avatakse valemite vaates vastavad valemid.

Valemite vaates on põhielemendiks WebView, mis kuvab lokaalseid HTML faile. Kõik valemid on GIF pildid, mis asuvad HTML failidega samas kaustas rakenduse sees. Uue teema valimisel näidatakse kasutajale aktiivsuse indikaatorit, mille kaotab WebView küljes olev onload sündmus.

Valemite sisestamiseks kirjutasin lihtsa veebiliidese, mis võimaldab tekitada kategooriad ning nende alla valemeid sisestada. Kui valemid on sisestatud, käivitan täiendava skripti, mis genereerib rakenduse jaoks vajalikud HTML failid ning koostab ka JSON formaadis sisukorrafaili, mille alusel rakendus faile näidata oskab.

Sisukorrafaili sisu on järgmine:
[
{
"title": "Aritmeetika",
"file": "f3f80b155d7d9af6c53bcfe23f1ea1a5.html"
},
{
"title": "Algebra",
"file": "589e1e9e690257c13858583381062e49.html"
},
{
"title": "Võrrandite lahendid",
"file": "54a2708351b891702815e787feed5f69.html"
},
{
"title": "Planimeetria",
"file": "7a1970deec26f4b79b4c245c03c5f345.html"
},
......
]
Nii on rakenduse sisu lihtne uuendada - tuleb genereerida uued failid (iga kord on failinimed unikaalsed, et vältida puhverdamist) ja rakendus loeb need andmed kindla nimega JSON failist kenasti sisse.
Kood on kirjutatud täielikult JavaScriptis (lisaks standardsetele võimalustele on kasutusel Appceleratori API’id). Toon siin ära põhiloogika bloki, mis laeb JSON failist sisukorra ja genereerib selle alusel sisukorra tabeli read.
// funktsioon laeb sisukorrafaili ja genereerib
// massiivi tabeli rea elementidega
function generateIndex(){
var data = [], json, rows = [], row,
file = Titanium.Filesystem.getFile(
Titanium.Filesystem.resourcesDirectory,
"topics", "quefile.json");
// lae failist JSON
if (file.exists()) {
json = file.read();
try{
data = JSON.parse(json);
}catch(E){}
}
// koosta tabeli read
for(var i=0; i<data.length; i++){
if(!i){
// globaalne muutuja
firstpage = data[i].file;
}
row = Titanium.UI.createTableViewRow({
title: data[i].title
});
// kuna tegu on tsükliga, loo lokaalne kontekst
// kahjuks bind puudub, seega vaja nikerdada
(function(f, t){
row.addEventListener("click",
function(){displayPage(f, t)},
false);
})(data[i].file, data[i].title);
rows.push(row);
}
return rows;
}
Kusjuures rakenduse skriptiosa on ainult 99 rida pikk ja saaks ka veel lühemalt, kuna see on optimeerimata, sisaldab katsete käigus tekkinud jäänukelemente jne.
Valmis rakenduse saab iPhone, iPod ja iPad seadmesse laadida siit.
NB! Et saada õigus iseenda(!!!) telefonis rakendust katsetada ning hiljem valmis rakendus AppStore‘i üles laadida, tuli liituda Apple Developers programmiga, mille aastatasu on $99. Kusjuures, makset ei saa teha online vaid tuleb välja printida avalduse vorm, täita see ära (sh. kanda vormile krediitkaardi andmed) ja see faksida (!!!) Apple numbrile. Kasutasin faksimiseks online teenust, kuhu laadisin üles PDF faili (allkirja ei pannud ise, vaid kopeerisin eesti.ee portaalist enda rahvastikuregistri andmete juurest). Kahjuks ei kasutanud SEB virtuaalkaarti vaid reaalset kaarti ning et igaks juhuks vältida tulevasi probleeme panin kasutatud krediitkaardi hiljem kinni. SEB virtuaalkaardiga seda muret poleks tekkinud.
Minu tasuta matemaatika rakendust on praeguseks AppStores alla laetud juba üle 1000 korra. Kuna tegu on eestikeelse rakendusega ning seda ongi alla laetud praktiliselt ainult Eestis (kusjuures iga allalaadimine tähendab üht unikaalset seadet, mitte mitu korda per seade), siis minu arust tegu täitsa toreda saavutusega :)
Kaubamärgi registreerimine ei ole keeruline, küll aga jube pikk protsess. Näiteks 27. märtsil 2009 (umbestäpselt 2 aastat tagasi) andsin Tr.ee OÜ, mille juhatusse ma tollal kuulusin, nime alt sisse kaubamärgi registreerimistaotluse nimele “Blog.tr.ee”. Aeg kulus, aegajalt tuli registreerijal (Tr.ee OÜ) järjekordse etapi puhul riigilõivu maksta ning siis selle kuu alguses (täpsemalt 07.03.2011) sai see lõplikult registreeritud.
Kokkuvõttes - kaubamärgi registreerimise protsess võttis aega 20 päeva vähem kui 2 aastat. Mina olin otseselt sellega seotud ainult alguses, kuna lahkusin ettevõttest juba 2009 a. suvel, kuid kuna olin taotluse esitaja, saadeti ka edaspidi kõik seonduv post minu aadressile.
Siinkohal mainiks ära, et viimasel ajal on mulle silma hakanud mitmel pool blogides kriitika Blog.tr.ee kohta seoses postituste mitte ilmumise ja aeglusega. Teema pole mulle sugugi võõras. Tundub aga, et asjad ei taha kuidagi paremuse poole liikuda.
Meenus, et kunagi ammu aega tagasi liikusid plaanid teha MTÜ Eesti Blogiliit, mis haldaks ise sarnast lehte kuna Blog.tr.ee laiutas turul ja ei toiminud alati korrektselt või ootuspäraselt. Kahjuks midagi sellist kunagi ei sündinud. Aga et asjale siiski nüüd tagantjärele (parem hilja kui üldse mitte) omalt poolt hoogu anda, algatasin avatud lähtekoodiga blogikataloogi projekti tööpealkirjaga Blogipunkt, millega võib igaüks kaasa lüüa või sellest soovi korral oma klooni teha. Ma ise ei tahaks väga valmis saiti hallata, sain seda Blog.tr.ee ajal küllalt teha, aga et anda soovijatele võimalus, siis saigi projekt ette võetud.
E-post oma olemuselt on üsna lihtne teenus. Sellisel kujul kui meie seda tunneme, on e-post töötanud sisuliselt aastast 1982 - mil loodi SMTP protokoll kirjade edastamiseks. E-kirju saadeti ohtralt ka varem, kuid neid edastati arvutist arvutisse FTP ehk failiedastuse protokolli abil, spetsiaalselt e-kirjade edastamiseks mõeldud protokolli veel polnud.
Sisuliselt võib öelda, et kui kiri mis saadeti välja aastal 1982 ning adressaadini jõudmata sattus mingisse interneti Bermuuda kolnurka, igavesse tsüklisse, siis sellest tsüklist pääsenult oleks praegune võrk võimeline sedasama kirja ilma mingite modifikatsioonideta endiselt adressaadini toimetama. Kõik täiendused, mis vahepeal on tehtud, on lisatud uue kihina olemasolevale, mitte ei ole põhimõtteliselt muudetud süsteemi ennast.
E-kiri koosneb laial saastus kolmest eraldi elemendist - kirja sisust, kirja päisest ja “ümbrikust”. Kirja pärises asub igasugune kirjaga seotud meta-info, näiteks mis on selle pealkiri ja kellele see on adresseeritud. Küllap paljud ei tea, aga tegelikult kirja päises olevad aadressid (To, Cc ja Bcc väljadel) ei mängi edastamisel mitte mingisugust rolli - need aadressid kuhu kiri tuleb edastada, määrab hoopis “ümbrik.”
Kirja päises olevad aadressid on ainult informatiivseks kasutamiseks e-posti kliendile ning spämmitõrjele. Tegelikud aadressid liiguvad kirjast eraldi info ehk “ümbrikuna” e-posti edastusserverilt -serverile.
SMTP serverile öeldakse MAIL FROM ja RCPT TO parameetritega ära esiteks kirja saatja ning seejärel kõik saajad, hoolimata kas need asuvad To, Cc või Bcc real. Kusjuures edastatakse ainult need aadressid, mida vastuvõttev server peab teadma. See tähendab, et kui e-posti klient võtab ühendust väljuva SMTP serveriga, siis vuristab ta ette kõik adressaadid, kuid kui väljuv SMTP server võtab ühendust vastuvõtva SMTP serveriga, edastatakse vaid need aadressid, mis kuuluvad selle konkreetse vastuvõtva serveri juurde.
Üldiselt liigub siis e-kiri järgmist rada pidi

Kirja enda ehitus on sarnane teiste tekstipõhiste protokollidega, nagu näiteks HTTP. Kiri algab päiseosaga, mis kestab kuni esimese tühja reani (kaks reaeraldussümbolit “\r\n” järjest), edasi järgneb juba kirja sisuosa.
Reegliks on, et üks päisekirje asub ühel real. Erandiks on vaid pikemad kui 80 sümboliga kirjed - need volditakse mitmele reale laiali, aga nii et esimene rea puhul algab tekst esimesest sümbolist, järgnevatel on esimeseks sümboliks alati tühik. Nii oskab vastuvõttev server hiljem read tagasi kokku voltida - juhul kui rida algab tühikuga, liidetakse see eelneva rea lõppu.
From: andris@kreata.ee
To: addressat1@example.com, addressat2@example.com,
addressat3@example.com, addressat4@example.com
Näiteblokis jätkub To: kirje uuelt realt kuna addressat3... ei alga rea algusest, vaid selle ees on tühikusümbolid.
Oluliseimad kirjed oleksid From, To ja Subject - kui need on täidetud, on kirja võimalik juba saata.
Vaikimisi on tekst 7 bitises US-ASCII kodeeringus. Kõik mis järgneb päise lõpus olevale tühjale reale, ongi kirja sisuks. Ilmselgelt jääb sellest väheks, kuna nii ei ole võimalik isegi täpitähti kasutada, hieroglüüfidest jms. rääkimata. Samuti ei ole erilisi võimalusi teksti vormindamiseks ega manuste lisamiseks. Kõigi nende nimetatud asjade jaoks võeti kasutusele multimeili laiendused (MIME), kuid nendest hetkel pikemalt juttu ei tee. Sisuliselt on tegu täiendava kihiga tavalise tekstiformaadi peal.
Seega kõige lihtsam kiri võiks välja näha nii
From: andris@kreata.ee
To: andris@node.ee
Subject: Kiri endale
Tere maailm!
Esimesed kolm rida moodustavad päise, järgnev tühi rida on päise lõpu markeerija ning rida “Tere maailm!” moodustab kirja sisu.
Seda, kas kirjeldatud e-kirja koostamise viis ka töötab või mitte, on igalühel võimalik kergelt järgi proovida. Vaja on telnet nimelist programmi ja ligipääsu SMTP serverile (soovitavalt mitte-autentimisega, kuna ise käsklusi trükkides on paroole raske sisestada).
Esiteks tuleb käivitada telnet SMTP serveri pihta. Mina kasutan näites hot.ee SMTP serverit, kuna see on Elioni võrgust kasutades vaba ligipääsuga.
telnet mail.hot.ee 25
Trying 194.126.101.116...
Connected to mail.hot.ee.
Escape character is '^]'.
220 hot.ee HOT-Relayhost1.estpak.ee
Server vastas teatega “220…” mis tähendab, et ühendus on avatud ja server on valmis meid kuulama. SMTP puhul tähistavad koodid algusega 2 ja 3 edu, aga 4 ja 5 ebaõnnestumist.
Järgmisena tuleb end identifitseerida ja anda teada mis tüüpi protokolli toetatakse, kas tavalist SMTP või laiendatud versiooni ESMTP. Seda saab teha käskudega HELO ja EHLO millele järgneb iseenda masina nimi. Näites kasutame tavalist SMTP versiooni ja seega on käskluseks HELO.
HELO minaise
250 HOT-Relayhost1.estpak.ee
Nüüd saab hakata “ümbrikut” kokku panema. Selle jaoks tuleb sisestada saatja aadress ja ükshaaval saajate aadressid. Need sisesatud aadressid saavad tegelikeks adressaatideks, kirja sees olevad on ainult informatiivse iseloomuga.
MAIL FROM:<andris@kreata.ee>
250 2.1.0 Ok
RCPT TO:<andris@node.ee>
250 2.1.5 Ok
Kui formaalsused on korraldatud, saab minna edasi juba tegeliku kirja edastamisega, selle jaoks tuleb kasutada ksäklust DATA. Edasi on kogu sisestatav tekst osa kirjast ning seda kuni üksiku punkti sisestamiseni omaette real. Vältimaks segadust, peab klient kirja edastades kirja sees kõik rea alguses olevad punktid topeltpunktidega asendama.
DATA
354 End data with <CR><LF>.<CR><LF>
From: andris@kreata.ee
To: andris@node.ee
Subject: Kiri endale
Tere maailm!
.
250 2.0.0 Ok: queued as 01E7F49A
Peale punkti sisestamist loeb server kirja sisu lõppenuks ning võtab selle edastamiseks üle. Klient võib nüüd ühenduse sulgeda.
QUIT
221 2.0.0 Bye
Connection closed by foreign host.
Selline on siis suures plaanis e-posti liigutamise mehhanism. Võibolla võtan kunagi ka MIME pikemalt lahti kirjutada, seniks aga võib vaadata minu e-posti saatmise kliendi Nodemailer lähtekoodi, mis on täiesti MIME sõbralik, võimaldades kasutada UTF-8 kodeeringus teksti, lisada manuseid jne.
Ja nüüd midagi, mis on mul huvitaval kombel siiani kahe silma vahele jäänud, aga mida lugesin Stoyan Stefanovi raamatust JavaScript Patterns ja mis tagantjärele tundub täiesti loogiline.
var a = b = c = 5;
Ei ole sugugi sama, mis
var a = 5;
var b = 5;
var c = 5;
Vaid hoopis
var a = 5;
b = 5;
c = 5;
Ehk et muutujatest b ja c saavad lokaalsete asemel hoopis globaalsed muutujad!
Igaks juhuks märgin ära veel samasse teemasse kuuluva, aga juba tuntud probleemi
a = b = [];
c = d = {};
e = f = 5;
Sellise omistamise korral ei saa me mitte 2 massiivi-, kaks objekti- ja kaks numbriväärtust, vaid kaks numbriväärtust (e ja f, mõlema väärtuseks nr 5) ja ühe massiivi- ning ühe objektiväärtuse.
a ja b ei ole mitte eraldi väärtused, vaid kaks muutujat, mis viitavad ühele ja samale massiiviväärtusele. JavaScriptis on objektide edastamine (ka massiiv on objekt) alati BY REFRENCE.
Seega lause
a = b = [];
võib lahti kirjutada ka kui
a = (b=[]);
ehk
b = [];
a = b; // BY REFRENCE!
Kaalusin kaua, kas hankida endale e-luger, oodata ära kuni iPad kohalikku kaubandusvõrku saabub või lugeda e-raamatuid arvutiekraanilt/telefonist. Kuna ka meie jaoks on mõnda aega avatud Amazoni e-raamatute pood, siis installisin arvutisse ja telefoni Kindle aplikatsiooni, mis neid raamatuid ette näidata oskaks ja proovisingi paari raamatut lugeda. Paraku ei olnud tulemus väga hea, ikkagi üsna tüütu on arvutiekraanilt pikemat teksti ette võtta. Ka iPadi tulek ei tundunud enam nii roosiline, kuna iPadi näol on tegu sisuliselt järjekordse arvutiekraaniga.
Ühesõnaga, otsustasin proovida e-lugerit. Eestis pakutav valik on üsna kehva, Rahva Raamat küsib Cool-er’i eest tutvumishinnaga 3900 krooni, mis on päris soolane. Koos Kindle raamatute müügi avamisega, hakkas aga Amazon tarnima Kindle e-lugereid ka Eestisse, kuid selle lugeja hind (kuigi tegu peaks olema tunduvalt parema seadmega kui Cool-er) on letil juba ainult $139 + kulud. Kuludeks on siis transport ja impordimaks. Pakkumine tundus soodne ja tellisingi ära.
Reedel panin tellimuse sisse, esmaspäevaks oli pakk Tallinnas (UPS kulleriga). Kuna pakki oli vaja tollis deklareerida, ei saanud kohe kahjuks kätte. Teisipäeva hommikul käisin tollis (esitada tuli UPS’i poolt e-postiga saadetud dokumendid + reisija deklaratsioon), maksin impordimaksu ära ja sain UPS’ist oma lugeri kätte. Väga kiiresti käis.
Hind kujunes siis järgmiselt:
Kokku siis 2153.98 kr, mis on Rahva Raamatu poolt pakutud Cool-er’i hinnast ligi kaks korda väiksem.
Seade oskab suhelda WiFi võrguga ning ka USB kaabli abil arvutiga (sama kaabel on kasutusel ka aku laadimiseks). Amazonist ostetud e-raamatud ilmuvad seadmesse võrgu olemasolul automaagiliselt, kuid peaks saama ka USB kaabli abil neid sinna saata. Tavalisi PDF faile jms võib seadmesse lihtsalt “lohistada,” kuna seade ilmub kaabliga ühendamisel arvuti töölauale tavalise välise kettana.

Kuigi testimise valdkond on suur ja lai, siis üks kindel asi mida tagada tuleb, on eri platvormide testimine. Alati ei ole aga kõiki võimalikke brausereid ja operatsioonisüsteeme käepärast ja tuleb kasutada alternatiivseid vahendeid. Kõige kiirem ja lihtsam nipp erinevate platvormide testimiseks oleks browsershots lehe kasutamine:
Alati ei anna browsershots pildid õiget tulemust, kuna brauserid ei ole kontrollitud. Võibolla näiteks on konkreetne brauser seadistatud nii, et test ei saagi seal läbi minna (näiteks on küpsised välja keeratud, kui neid oleks vaja jne), samas aga kuna puudub info konfiguratsiooni kohta, on raske ka järeldusi teha. Küll aga kui kõik on roheline, võib omadega rahul olla.
Mina olen seda strateegiat kasutanud näiteks jStorage testimiseks (testleht).
Kes on vähegi HTML’iga kokku puutunud, teab et linkidel käib ees protokolli nimetus- tavalingi puhul on selleks http: või https:, FTP serveri puhul ftp:, e-maili aadresside korral mailto: jne. Klikkides lingil, avatakse protokolliga seotud rakendus. Veebilinkide puhul on selleks brauser ise, aga ftp, mailto jne juba reeglina mõni muu.
Erinevad aplikatsioonid saavad registreerida brauseris ka oma kohandatud protokolle, nii teeb näiteks Skype - skype:kasutajanimi?call. Vähe aga teatakse, et näiteks Firefox brauseris saab protokolli kindla rakendusega siduda ka suvaline veebiteenus - sellisel juhul on protokolli avavaks rakenduseks enam mitte väline rakendus vaid määratud veebilink, mis saab parameetriks lingi väärtuse. Nii näiteks saaks veebipõhine e-posti klient suunata endale kõik mailto: lingid - kasutaja klikib sellisel lingil, kuid Outlooki või Thunderbirdi avamise asemel avatakse veebipõhine e-posti teenuse leht.
Protokolli saab enda veebiteenusega siduda järgmise käsuga:
navigator.registerProtocolHandler(protocol,
handling_url,
name);
Kus protocol on protokolli eesliide (näiteks mailto), handling_url on aadress, kuhu päring suunatakse (aadressis olev %s asendatakse lingi väärtusega, nb - aadress peab asuma samas server, kui päringut teostav veebileht) ja name inimloetav protokolli nimetus. Loomulikult ei lisata sellist protokolli registreerimist automaatselt, vaid enne küsib brauser kasutaja luba nagu kõigi muude taoliste tegevuste korral.
Kui kasutajalt küsida mailto linkide suunamist järgmise käsuga
navigator.registerProtocolHandler("mailto",
"http://emaili-server.ee/new?to=%s",
"Minu E-post");
ja seejärel kasutaja klikib suvalisel veebilehel järgmise kujuga lingil
<a href="mailto:kasutaja@server.ee">saada kiri</a>
siis avab brauser veebilehe aadressiga
http://emaili-server.ee/new?to=mailto:kasutaja@server.ee
Katsetada saab siin ja täpsemalt uurida Mozilla MDC Web-based protocol handlers lehelt.
Töötab - Firefox 3.x. Webkiti core’s on olemas juba aasta aega kuid miskipärast ei Chrome ega Safari seda veel ei toeta. Tulevikus aga kindlasti. IE kohta ei oska öelda.