Javascript får systemadgang
Nu skal Javascript-webprogrammer kunne få adgang til information fra systemet, som tidligere var utilgængelig.
I hvert fald hvis et nyt forslag fra World Wide Web-konsortiet (W3C) får magt, som det har agt. Bag forslaget står Intel og norske Opera.
Der er ikke tale om input/output så som netværk og filer, men derimod om egenskaber og værdier fra systemets hardware.
Det er for eksempel oplysninger om strømforsyning, netværkets båndbredde, tilgængelige lyd- og videocodecs, samt oplysninger om inputenheder så som kamera, mikrofon og pegeredskaber. I den mere eksotiske ende er der oplysninger om systemets omgivende temperatur, lufttryk og lysstyrke, hvis systemet eller enheden er udrustet med de rette sensorer.
Informationen fra systemet vil kræve brugerens godkendelse, skriver forslaget, ligesom det kendes fra Geolocation-API'et, hvor en browserapplikation kan få adgang til systemets geografiske position hvis brugeren giver lov.
I de tilfælde hvor det giver mening, vil det også være muligt at sætte systemets egenskaber, som f.eks. skærmens lysstyrke. Også her vil det kræve accept fra brugeren at få handlingen gennemført.
API'et skal implementeres via objektet navigator.system, som skal have tre metoder get, set og watch. Information hentes ved hjælp af asynkrone callback-funktioner, så som i eksemplet herunder, hvor funktionen "succes" kaldes under en given betingelse:
navigator.system.watch("Power",success,null,
{lowThreshold:0.2});
function success(power) {
alert("Low battery level: "+power.level);
};
Forslaget kan findes hos W3-konsortiet via det eksterne link herunder.
Kommentarer (4)
For sprog der kan køre på mange platforme, er det netop et krav, at deres kode ikke må indeholde dele, der afhænger af platformen. Årsagen er, at fejl derved løses forkert - ved at tage højde for platformen, og ikke ved at rette fejlen, der gør at sproget ikke er platformsuafhængigt som det burde.
Når der går et stykke tid, vil udviklerne ikke mere "gide" at supportere ældre platforme, eller mindre anvendte platforme, og så ryger platfomsuafhængigheden totalt. Den typiske besked, på en mindre benyttet platform bliver så: "Denne side, understøtter kun lydkort af mærket osv..."
Oprindeligt, var idéen med HTML, at det skulle være uafhængigt af computer og skærmstørrelse. Sådan er det ikke mere - muligheden for at "tjekke" skærmstørrelsen, har for længst fået udviklerne til at kun supportere en bestemt antal pixels vandret og lodret. Selve idéen, med HTML er derfor død. Hvis man ikke tillader tjek på hardwaren, så presses udviklerne til, at ænde standarden, således den faktisk fungerer - og opsætter siderne pænt, uanset skærmstørrelsen. Men, når man "bare" kan tjekke, så sætter de ikke hjernen igang.
Nogle, går endog efter at bevise det ikke kan gøres. Det burde man måske have indset, før man fandt på HTML. Naturligvis, vil det som regel være muligt at løse problemerne, men interessen er minimal - fordi der er virksomheder, der kan finde på "aftaler", så det bliver gunstigt, at kræve skærme af en vis størrelse. På den måde sikres, at kunderne skal have nyt, og at miljøbelastningen optimeres, da alle hele tiden skal have nyt.
-
0 -
0
I danmark virker det måske ikke så relevant at kunne måle hastigheden på klientens forbindelse, men mange andre steder alene i europa giver det rigtig god mening da ikke alle lande er lige godt med.
Muligheden for at måle klientens hastighed giver store muligheder for at tilpasse sidens indhold og derved stadig give en god oplevelse selv om en forbindelse er langsom. Mulighed for at vælge billeder med lavere opløsning osv.
Lidt det samme som muligheden som vi allerede har nu ved skærmstørrelse, for her kan man også tilpasse siden til den enkelte. For det er da ikke fedt at have en opløsning på 1680x1050 og så ramme en side der er optimeret til at kunne blive vist på alle skærme dvs. en opløsning helt ned til 800x600.
-
0
-
0
Javascript breder sig meget i disse år - det bruges i mange andre sammenhænge end i web-applikationer, hvor det har sin oprindelse. Jeg tænker på scripting i Adobes applikationer (udvidelserne til Adobe Reader er ofte skrevet i Javascript), Mac OS X' widgets, Palm WebOS og Firefox.
Grunden er nok, at Javascript - på nær et par uheldige sider - er et ganske elegant sprog. Klasseløse objekter føles naturligt efter nogen tid og elementerne fra funktionsprogrammering gør det dejligt kompakt.
Google er gået foran med deres Chromium OS som i virkeligheden blot implementerer en terminal-løsning. Der er ikke noget, der hindrer dig i at implementere det samme med en minimal Linux og Firefox (eller Windows og Internet Explorer).
"Software as a service" betyder rigtigt meget Javascript (på klient-siden) i denne terminal/browser-verden. Da der ikke altid er internet-forbindelse (når du kører fra Ørestad st. mod Kbh H er der f.eks. et dødt område), er det smart at applikationerne kan være offline (eller køre helt lokalt). Og når du kun har din browser, er det praktisk at dine terminal-program (klienten) også kan holde styr på strøm-forbruget og huske at gemme (evt. lokalt i din browser - local storage er en del af HTML 5) når der kun er et par minutter tilbage.
Set i ovenstående perspektiv, giver W3C's ideer til nye Javascript API'er fuldstændig mening.
-
0
-
0
