Nettbasert blir nettuavhengig

[abene]

Med det nye utviklingsverktøyet Google Gears kan nettbaserte programmer gjøres nettuavhengige.

Les mer

[tZar]

Utrolig kult, og mye bedre en tidligere måter å lage offline applikasjoner på.

Desverre gjenstår fortsatt problemet med hvordan skal man synce dataene.

For en middles stor applikasjon så kan fort en sync-engine bli flaskehalsen, spessielt hvis det er en applikasjon som allerede eksisterer.

For nye prosjekter vil det derimot kunne være noe enklere å få til.

[qualbeen]

flott tiltak, men trenger vi slikt i dag? Omtrent overalt i byer er det jo et eller annet trådløst nettverk å koble seg opp på? I tog og bil derimot er jo slikt kjekt

[MaHuJa]

Følgende kan vel kalles en middels informert mening; spesielt siden jeg ikke har gjort stort i javascript/ecmascript til å begynne med, og ikke har gravd særlig dypt i "googears".

 

Man får altså tre ting på en gang her.

 

En ser ut til å være en metode å få programkoden lagret lokalt, til brukeren evt skulle trenge programmet uten å være online. Dette er tilsvarende en instruksjon til browseren om at dette er noe som den må (som i "garantert") holde ekstra godt på i cachen sin. (Jeg lurer nå på hva som hindrer annenhver nettside å legge inn dette? Antakelig er det en grunn til at noe slikt ikke er så veldig tilgjengelig i webbrowsere normalt...)

 

To ser ut til å være lagringsmuligheter som overgår det som ellers er tilgjengelig i cookies. Dette vil potensielt kunne ha akkurat samme problemene som cookies har (hatt), med unntak av at de ikke overføres i hver request. (Hvis du ser på alle begrensningene som er innført på cookies, så gjelder antakelig de fleste grunnene også for gears databasen.)

 

Tre er en måte å kjøre bakgrunnsoppgaver på. Alternaltivet ville fort bli å lage noe brukeren må vente på, eller å åpne et ekstra vindu som kjører denne oppgaven. Hvis ikke denslags vil lide under timeouts eller andre slike begrensninger. Men er den tillatt å bruke betydelige mengder cpu-tid? Minne? (Eks; kan en side starte en prosess som starter en kopi av seg selv nå og da?)

 

 

Disse er derfor hovedsaklig om å kunne garantere at visse tjenester er tilgjengelig, uavhengig av browseren eller dens konfigurasjon. Noen brukere slår av cookies, men websider skal fremdeles ha tilgang til å lagre ting på brukerens disk ved å bruke googears. (Lagringsmulighetene er heller ikke lenger så begrenset av browseren, som f.eks. setter en streng makslengde på en cookie)

En betydelig del av poenget mitt er at dette er ting disse brukerne kan ha skrudd av for en grunn, men hvis googears er tilgjengelig for alle websider likevel har det veldig lite for seg. (Og med snakket om å gjøre standarder ut av det, tror jeg det er sånn.)

 

 

"The basic JavaScript language and the standard objects present few security risks. Most risks come from the way in which access is provided to the execution environment, which is most commonly the browser." (wikipedia)

 

M.a.o. Mye av dette er ting som ikke var inkludert fra før i javascript rett og slett fordi et program laget i javascript i utgangspunktet kommer fra kilder (hvilken som helst webside...) man ikke kan stole nok på til la å gjøre stort med maskinen.

Eller sagt på en litt mer direkte måte: Javascript er ikke et passende programmeringsspråk for programmer som jo trenger litt tilgang til maskinen som kjører det. (Inkludert lagringsplass)

 

Javascript er (tydeligvis) brukbar for å lage "online" applikasjoner. Poenget er at der er web browseren nesten en "tynn klient".

(se http://en.wikipedia.org/wiki/Thin_client for mer informasjon om de.)

Men for å dele ut systemressurser, som det trenger i offline ("Thick client") - og som googears handler om - blir js fort et dårlig valg nettopp fordi herr hvemsomhelst (eller kanskje herr popunder advertiser og co, som sannsynligvis vil adoptere dette hurtig) kanskje kan forsyne seg grovt.

 

Google Gears gir et par flere kroker et ondsinnet skript kan henge seg på. At programmer i den klassen de prøver å lage noen av, trenger disse krokene, er jeg helt med på. Men min mening er at heller enn å lage disse krokene, burde man bytte programmeringsspråk.

 

Uansett, de beste offline applikasjoner er neppe skrevet i Javascript. De er antakelig heller skrevet i "mer tradisjonelle" programmeringsspråk. For de som er hovedsaklig online stiller saken seg noe annerledes, men jeg mener Java antakelig er en bedre vei å gå her. Som et eksempel, se http://housecall.trendmicro.com - som i utgangspunktet er et online program det også. (Hvis ikke Java er bannlyst innen google fordi det er proprietært e.l.?)

 

Produktet er sikkert bra i seg selv, men jeg mener de tar feil utgangspunkt; Javascript burde brukes til å forbedre en HTML-basert side, ikke lage en stor/tung applikasjon som bare er innkapslet i html-headere. Til det er andre verktøy bedre egnet.

 

-

Som sagt, mye av dette er mine meninger (og jeg har kanskje faktafeil også) og er derfor åpent for diskusjon.

[Martin Lie]

(og jeg har kanskje faktafeil også)

I hvert fall én. Java er (så å si 100%) tilgjengelig under GPL, og er vel dermed ikke proprietært lenger?

[:chribruu]

flott tiltak, men trenger vi slikt i dag? Omtrent overalt i byer er det jo et eller annet trådløst nettverk å koble seg opp på? I tog og bil derimot er jo slikt kjekt

8757281[/snapback]

 

 

Er fortsatt en god del mennesker her i landet som ikke bor i en by, og sitter på mer eller mindre stabile nettforbindelser vettu

[RattleBattle]

flott tiltak, men trenger vi slikt i dag? Omtrent overalt i byer er det jo et eller annet trådløst nettverk å koble seg opp på? I tog og bil derimot er jo slikt kjekt

8757281[/snapback]

 

 

Er fortsatt en god del mennesker her i landet som ikke bor i en by, og sitter på mer eller mindre stabile nettforbindelser vettu

8769675[/snapback]

Og hvis du for eksempel har en kalender, kan det være kritisk at du mister nettforbindelsen i noen timer.