Mozilla schetst plannen voor Firefox 3.2

In de volgende major update van Firefox zit de tekstcommando-interpreter Ubiquity ingebakken. Ook komt er een model om webapplicaties zich meer te laten gedragen als desktopprogramma's en een manier om het uiterlijk van de browser te wijzigen

Firefox-architect Mike Connor heeft tegenover PC Pro verschillende nieuwe features genoemd die in versie 3.2 van Firefox zullen belanden. Vermoedelijk althans, want er is een kleine kans dat versie 3.2 dit jaar niet verschijnt maar dat er volgend jaar gelijk naar versie 4 wordt doorgestoomd.

De volgende grote update zal volgens Connor standaard de 'commandline-interface' Ubiquity bevatten, die momenteel in bètavorm verkrijgbaar is. Hiertoe werd medio 2007 de aanzet gegeven door Mozilla-usability-expert Alexander Faaborg, die ervoor pleitte power users beter in gedachten te houden in het muiskliktijdperk, Hij stelde dat bepaalde opdrachten via commandline-opdrachten gemakkelijker uitvoerbaar zijn. Faaborg implementeerde destijds commando's om bijvoorbeeld snel door bookmarks te doorzoeken, maar zei erbij dat het om 'wilde ideeën' ging die niet in Firefox 3 zouden worden geïmplementeerd - iets waar hij waarschijnlijk dus ongelijk in krijgt. Connor noemt de respons op Ubiquity 'fantastisch'.

Firefox Ubiquity: toekomstmuziek

Een andere feature die Connor aangestipte is lightweight theming, waarmee het uiterlijk van de browser kan worden gewijzigd. Hiervoor is het niet nodig om aparte extensies te downloaden. Ook beschrijft de Firefox-architect de eveneens nieuwe feature Prism, dat het voor webapplicaties zoals Gmail mogelijk moet maken zich meer als desktop-applicatie te gedragen, zodat ze bijvoorbeeld vanaf het startmenu kunnen worden benaderd. Maar belangrijker is dat Prism beoogt om de focus van de browser weg te nemen, immers: browsercontrols zoals een backbutton of adresbalk hebben weinig tot niets met de interactie van de webapplicatie te maken. Prism staat onder meer het starten van een applicatie op basis van een initialisatiebestand toe, en er wordt gewerkt aan het draaien van apps in hun eigen 'sandbox'. Dit zou niet alleen de veiligheid ten goede komen, maar het ook mogelijk maken om door het scheiden van cookies bijvoorbeeld met verschillende Google-accounts in te loggen.

Ondanks dat Prism elementen leent van Googles Chrome-browser benadrukt Connor dat Mozilla dat bedrijf niet volgt met het laten draaien van tabs in aparte processen. Dat kost volgens hem te veel geheugen: iedere tab heeft immers een basishoeveelheid nodig en het totale gebruik zou dan snel uit de hand kunnen lopen. Wel zegt hij dat het misschien een goed idee is om bijvoorbeeld alle tabjes die bij een gegeven domein horen in hun eigen proces te draaien.

Reacties (45)

[Verwijderd]

Ook komt er een model om webapplicaties zich meer te laten gedragen als desktopprogramma's en een manier om het uiterlijk van de browser te wijzigen

Dit is inderdaad waar we naartoe gaan met web-applicaties. Het gaat om de fucntionaliteit, niet het venstertje van de browser. Daarom is er ook zoveel te doen om de rendering engine van MS die niet verwijderbaar is. Daarom is Opera zo vasthoudend.
Het gaat niet om het venstertje browser wat concurrerend is, niet om het IE-icoontje dat wel of niet zichtbaar is. Het gaat erom dat web-applicaties in de nabije toekomst direct de rendering engine zullen aanspreken via een http-laag die direct hier naartoe omgeleid, zonder dat er een browser zichtbaar wordt.

En als daar de IE-rendering engine zit, en iedere andere engine niet toegelaten kan worden, dan krijgt MS het monopolie op het gebied van webapplicaties.

Niet alleen web-applicaties, maar in feite alle applicaties kunnen hun interface in html schrijven en direct de rendering-engine inschakelen.

Laten we het aan MS over, dan blijven applicaties ondanks de platform onafhankelijke html-standaard toch platform afhankelijk, want MS propt er gewoon proprietary in, zoals ActiveX. Dat is ook de redenw aarom een extreem onveilig technisch concept zoals ActiveX na meer dan tien jaar nog steeds bestaat. Het is de manier van MS om de rendering engine exclusief aan Windows te koppelen. Dat moet nu opnieuw de zaak redden.
Laten we ook andere producenten rendering-engines als default engine installeren, dan krijgen we een platfortm onafhankelijk applicatie-platform. Dat is wat MS vreest. Daarom is de zaak van opera zo belangrijk.

Het gaat om niets minder dan de toekomst van het applicatie-platform, of MS-proprietary, of een open markt.

[Reactie gewijzigd door Verwijderd op 5 augustus 2024 08:24]

[Verwijderd]

En als daar de IE-rendering engine zit, en iedere andere engine niet toegelaten kan worden, dan krijgt MS het monopolie op het gebied van webapplicaties

Maar er is nog nooit sprake geweest van de situatie dat MS het tegenhield dat software een andere renderengine gebruikt. Beetje FUD dus...

Uiteraard is het wel zo dat MS software vaak direct naar de IE render engine linkt, maar dat is o.a. omdat het de enige mogelijkheid is. O.a. vanwege exact de problemen die men hier in dit artikel aankaart... dat de applicatie alleen enkele delen van de engine wil gebruiken, en niet een compleet browser window wil zien.


Als men slim is, zou men nu samen met Microsoft een framework moeten opstellen, waarin applicaties een common interface naar een browser engine krijgen, en de consument zelf kan uitzoeken welke engine hij wil gebruiken. Scheiding van renderengine en front-end.

[Verwijderd]

Maar er is nog nooit sprake geweest van de situatie dat MS het tegenhield dat software een andere renderengine gebruikt.

Toch wel, er zijn standaard systeem API's die in deze context bestaan, en die roepen de IE (Trident) rendering engine direct aan.

Uiteraard is het wel zo dat MS software vaak direct naar de IE render engine linkt, maar dat is o.a. omdat het de enige mogelijkheid is.

Dat is niet zo, in feite zou het mogelijk kunnen zijn dat iedere rendering engine op de plaats van Trident gaat zitten, en dan op de systeem-calls zou reageren.
Dan zou MS Software niet meer standaard Trident aanroepen, maar de rendering engine die voor dat doel op die plaats staat.

Als men slim is, zou men nu samen met Microsoft een framework moeten opstellen, waarin applicaties een common interface naar een browser engine krijgen

Ik kan het niet beter zeggen. Precies dat is de inzet van Opera/EC.
De rendering-engine API's moeten dan wijzen naar een geregistreerde rendering engine.
Dit dwingt MS dan ook, omdat niet bekend is welke rendering-engine er in het systeem werkt, om alle functionaliteiten in zuiver gestandaardiseerde coderingen uit te voeren.

Dan is iedereen gelukkig, en is er open concurrentie mogelijk, ook in de toekomst.

[Reactie gewijzigd door Verwijderd op 5 augustus 2024 08:24]

[noes]

Ik vind t er toch wel n btje op lijken hoor:

• Exchange 2003 webmail applicatie is alleen in zijn volle glorie te zien in IE6+.
• IE 6 en IE 7 zijn niet w3 standards compliant.
• Windows Update draait alleen op IE
• Windows Virtual Server configuration manager heeft IE 6 of 7 nodig (terwijl die ook vanaf een andere machine dan de WM Server in kwestie te openen is). Dit geldt voor meer vergelijkbare programma's, ik geloof ook TSweb (Remote Desktop for Web) en de web configuratiemanagers van Windows Media Services en IIS.

[Reactie gewijzigd door noes op 5 augustus 2024 08:24]

[jbdeiman]

De browser wordt steeds meer de tool om web-applicaties/ websites mee te bekijken, en niet een heel programma op zich. Ik hoop overigens wel dat die add-ons (vooral voor ontwikkelaars handig bijv: Developer toolbar) gewoon beschikbaar blijven. Steeds meer programma's verbergen ook de standaard: File, Edit, View etc. opdrachtenbalk, zodat er meer ruimte over blijft om te kunnen werken in de webapplicatie.

Onderandere daarom is Opera zo vasthoudend, het is (en blijft) prima mogelijk om een Browser naast IE te installeren, het is alleen het standaard meeleveren (en niet kunnen missen van IE om met Windows te kunnen werken) waar Opera (en ook andere OpenSource browsers) boos over zijn. Zonder IE werken heel veel dingen in Windows niet of niet goed, een andere browser kan hetzelfde als IE, maar dat wordt niet mogelijk gemaakt, misschien zelfs wel geblokkeerd.
Als ik opera voor bestandsverkenning zou willen gebruiken, (bij wijze van) dan moet dat gewoon kunnen. Het "verplicht hebben" van IE om met windows te kunnen werken, maakt het voor andere browserontwikkelaars onnodig lastig om te kunnen concurreren.

[SuperNull]

Wat jij zegt is zeker een goed verhaal, maar de strategie van MS om mensen aan het Windows platform te binden zijn eenigzins veranderd lijkt het.
ActiveX is zo goed als dood, maar MS is nu .NET aan het pushen. Dit verhaal is een goed voorbeeld. Een andere browser (FF) is goed, maar de 'ClickOnce' applicaties zullen over het algemeen wel Windows moeten hebben aangezien .NET op andere platformen lang niet zo goed werkt.
Als .NET voor online applicaties populair wordt, maakt het marktaandeelverlies van IE niet veel uit. Mono zal toch toch nooit zo lekker werken als de 'echte' .NET op Windows.

[Verwijderd]

Silverlight/dotnet (browser/client-side dotnet) is inderdaad een volgend gevaar dat de platform-onafhankelijkheid bedreigt.
Miguel de Icaza doet voor MS een goede taak om platform-onafhankelijkheid te suggereren, maar de resultaten zijn al jaren tweederangs.

[Verwijderd]

Wanneer webapplicaties buiten de webbrowser draaien, afscheid nemen van de controls die we gewend zijn dan zijn het wellicht geen webapplicaties meer. Het zijn dan gewone internetapplicaties geworden die hooguit bepaalde technologie gemeen hebben met web-pagina's. En toevallig communiceren over poort 80. Voor de weergave op een scherm gebruiken ze een HTML DOM, het zou evengoed iets anders kunnen zijn (PDF, OPENGL whatever).

De vraag die je dan moet stellen is hoe goed de webstandaarden zijn om in zo'n andere context toe te passen. Javascript is een taal waarin opmerkelijke zaken zijn gerealiseerd, maar als het op programmabouw aankomt zijn er betere kandidaten. De HTML DOM is ooit bedacht voor one time rendering en niet voor herhaald updaten binnen hetzelfde scherm. Wil je dat toch dan codeer je je suf. Code once run everywhere kun je wel vergeten - testen zult gij - totdat u groen ziet van ergernis en uw projectbudget knalrood is.

Voor de bouw van een enigszins degelijke internetapplicatie heb je veel nodig. Meer dan Javascript nu te bieden heeft. Ontbrekende delen worden erbij geknutseld in 'frameworks' hetgeen zware applicaties tot gevolg heeft en waarbij heel veel werk wordt overgedaan dat al veel eerder in onder andere Java volwassen is geworden. Ik zou daarom groot voorstander zijn om Java een grotere plaats te geven binnen de webbrowseromgeving. Waarbij we objecten op een webpagina rechtstreeks en 'compiler-safe' kunnen benaderen in plaats van via gekunstelde 'getElementByid'-achtige oplossingen.

[Verwijderd]

De HTML DOM is ooit bedacht voor one time rendering en niet voor herhaald updaten binnen hetzelfde scherm.

Het hangt veel van de soort toepassing af. Veel toepassingen in het bedrijfsleven zijn data-presentaties. In AJAX is dit prima geregeld en werkt het heel goed.

Maar er zijn ook toepassingen die minder geschikt zijn voor web-applicaties, dit zijn toepassingen die een voortdurend up to date houden van een complexe grafische weergave verlangen.
Maar ook hier is meer mogelijk dan in de eerste instantie lijkt, precies zoals je zegt, door Java, Flash, andere technieken, maar toch zullen veel van deze applicaties nooit web-applicaties worden, en dat is op zich geen probleem.

Het wachten is overigens tot concepten zoals Citrix of X-Windows een API gaan ontwikkelen richting Web-applicaties, en op een of andere manier een samenwerking vinden met AJAX achtige technieken.
Vooral voor Citrix is dit van levensbelang, want naast de Fat-cliënt, zullen ook Citirx-vensters last gaan ondervinden van de concurrentie van web-applicaties. (wat zou je nog een applicatie als venster gaan exporteren terwijl je toch ook dat relevante data kan exporteren)

[killercow]

In ajax is dit prima geregeld?

wtf, ben je een manager of heb je werkelijk ooit iets gecode?

Ajax is niks, en zeker niet zoals jij het nu uitlegt.
De Dom kun je aanspreken met javascript, die dan aan de andere kant eventueel via xml/json data van de server plukt, _dat is ajax_ niks meer, niks minder.

Het manipuleren van de DOM aan de hand van gegevens van een server.

Citrix kan hier niks mee, net als Xwindows dat niet kan, de grafische toolkits spugen geen html uit maar bitmapjes, of eventueel vectors, zolang dit zo blijft kun je ook geen ajax gebruiken om deze dom te manipuleren.

[Verwijderd]

wtf, ben je een manager of heb je werkelijk ooit iets gecode?

Ooit van beleefdheid gehoord?

AJAX is goed, veel goede web-applicaties werken op basis van AJAX concepten.
Dat Citrix hiermee niets kan schreef ik ook al, fijn dat je dat herhaalt en specificeert.

[Reactie gewijzigd door Verwijderd op 5 augustus 2024 08:24]

[elmuerte]

Je praat onzin.

DOM heeft niks te maken met renderen, zeker niet met 1 keer renderen. DOM is juist bedacht om een document live te updaten.

Code moet je altijd testen tot dat je groen ziet van ergernis. Daarom is er ook het advies voor 3 testers per 1 developer.

Compile-once-run-everywhere is nooit een realiteit geweest. Je bent altijd afhankelijk van de een VM implementatie, en ook machine restrictions.

Wat ontbreekt er dan in de JavaScript taal? Of heb je het over de library functionaliteit (zoals DOM, XMLHttpRequest, ...)?

En "compiler-safe"? Bedoel je static type checking?

[user109731]

Hier is een tutorial voor Ubiquity te vinden. Zo te zien werkt het best handig: je kunt een stuk tekst selecteren, win+space indrukken en dan een commando als "translate to english" opgeven, of "email to ..."

[Reactie gewijzigd door user109731 op 5 augustus 2024 08:24]

[surfdude]

Ubiquity rules! Echt het proberen waard

[Spacespider]

Heb Ubiquity net even geïnstalleerd. Dat werkt echt heel gaaf!

Als de CLI ook zo gaat werken in Firefox 3.2 denk ik dat het best wel iets kan worden...

[DLGandalf]

Het enige wat ik mis is integratie met meer dan alleen gmail. Wanneer je het email-to commando gebruikt.
Dus de grote spelers:
-outlook,thunderbird
En voor linux
-Evolution en kmail
zouden wel ondersteunt mogen worden, dat ze hun eigen thunderbird ondersteunen is helemaal raar

[Verwijderd]

Ik heb het al een tijdje geinstalleerd staan en wat ik merk is dat het Firefox mét Ubiquity ongeveer 2 á 3 keer zo lang kost om op te starten. Hebben jullie daar ook last van?

[isama]

Wel zegt hij dat het misschien een goed idee is om bijvoorbeeld alle tabjes die bij een gegeven domein horen in hun eigen proces te draaien.

Meestal heb ik iig in bijna ieder tab een andere site open staan...
Verder klinkt het erg gaaf! vooral een cli voor je browser!

edit: typo

[Reactie gewijzigd door isama op 5 augustus 2024 08:24]

[Otherside1982]

Wel zegt hij dat het misschien een goed idee is om bijvoorbeeld alle tabjes die bij een gegeven domein horen in hun eigen proces te draaien.

Dat lijkt mij inderdaad ook een goed idee, zodat de resources (scripts, images, ...) die gemeenschappelijk zijn voor alle pagina's van 1 domein, maar in de geheugen cache zitten van 1 proces.

Als ik het goed op heb, is dat dan ook exact wat Chrome doet. Als ik tweakers.net lees bvb, dan open ik ieder interessant artikel in een tab. Het taakbeheer van Chrome geeft dan aan dat al die tabs in hetzelfde proces draaien.

[surfdude]

Volgens mij is het idee hierachter dat 'we' steeds meer online gaan doen. Heb je al 's naar het online office pakket van Google gekeken? Dat ziet er al best aardig uit.
Dus het kan (straks) best dat je een webmail, je kalender, een Word/tekstdocument en een Excel/spreadsheet open hebt staan allemaal via het Google domein
Aangezien je maar met een van die applicatie tegelijk (echt) bezig kunt zijn, kan het voordelig zijn als dat een process blijft en maar een processorcore bezet kan houden...

Het is heel belangrijk dat ze hier bij Mozilla goed over nadenken, want zij hebben 'alleen maar' een browser en moeten ervoor zorgen dat de applicaties van MS en Google zo goed mogelijk zo niet het beste draaien in Firefox.

[kozue]

Aangezien je maar met een van die applicatie tegelijk (echt) bezig kunt zijn, kan het voordelig zijn als dat een process blijft en maar een processorcore bezet kan houden...

Wat vind jij er voor voordeel aan dat er maar 1 processorcore bezig is met werk? Met de huidige trend om zoveel mogelijk cores in een cpu te stoppen (4,8, 16?) is het juist efficienter om het uit te splitsen over alle cores, en als je 8 tabs open hebt, al die tabs in theorie een hele core leeg kunnen trekken. Denk bv aan een flashplugin die een youtube video afspeelt (eventueel in de achtergrond, voor alleen het geluid), terwijl je met andere webapps bezig bent, zoals gmail, googledocs, webmessenger, etc. Dan wil je niet dat die andere apps traag reageren omdat de flashplayer zoveel cpu power nodig heeft en de core waar de browser op draait 100% loopt.
Die andere cores kun je net zo goed efficient inzetten. Cpu power is net als netwerkbandbreedte. Als je het niet gebruikt is het voor altijd verspilt.

[Little Penguin]

Het is heel belangrijk dat ze hier bij Mozilla goed over nadenken, want zij hebben 'alleen maar' een browser en moeten ervoor zorgen dat de applicaties van MS en Google zo goed mogelijk zo niet het beste draaien in Firefox.

Waarbij Mozilla daarbij ook weer neutraal tegenover zowel Microsoft's webapps als ook Google's webapps staat.

Met andere woorden, als men een goede ervaring aanbied aan de gebruiker in het algemeen en ook een adequate ervaring in alle webapps. Als ze dat doen dan zal er altijd een markt voor Mozilla Firefox blijven...

[kozue]

Mozilla zal vast wel willen dat MS webapps goed werken in firefox, alleen heeft MS altijd de attitude om alles wat je niet met MS software kan, links te laten liggen. Dan kan Mozilla nog zo goed bezig zijn met prism, maar als MS met de attitude "we supporten alleen zaken die IE aan kan" rondloopt schiet Mozilla daar niks mee op, en loopt MS zoals gewoonlijk de ontwikkeling van het internet weer eens te vertragen.

[Luuk1983]

Of hij bedoeld het domein intranet, het domein internet, domein lokaal etc. Dat lijkt me ook niet onlogisch. Dat zou de veiligheid te goede komen. Internet Explorer opent trusted sites bijvoorbeeld ook altijd in een apart proces.

[Tjeerd]

Die CLI doet me een beetje denken aan Vimperator.

[Verwijderd]

Ik denk dat Mozilla door deze update / upgrade een groot marktdeel afsnoept van Internet Explorer. In feite doen ze dat al maar ik denk dat deze voor een grote sprong gaat zorgen.

Als je nagaat hoeveel muisklikken je moet doen om van a naar b te komen en nu zou je het gewoon door deze functie binnen een paar woorden en een paar klikjes doen.

Scheelt tijd en minder kans op rsi .


Goeie zet van Mozilla.

[himlims_]

probeer eens mousegestures als je dat al niet hebt; er gaat een wereld voor je open als je ze onder de knie hebt
kan me geen browser meer voorstellen zonder (opera) maar FF doet hier net zo goed aan me

[DitisKees]

Is dat wel zo'n handige naam? Kunnen we weer mooi in de war raken met https://wiki.ubuntu.com/Ubiquity

[DLGandalf]

Er staat ook een namechange te wachten voor de stable release in firefox 3.2

[jj71]

Ach ja, maar die Ubiquity (het installatieprogramma van Debian / Ubuntu) is heel iets anders, en is niet iets waar de meeste mensen dagelijks iets mee te maken hebben. Ik denk dat het met de verwarring dus wel zal meevallen.

[i-chat]

Mozilla kennende - of beter gezegt firefox kennende heeft ie wel gelijk wat betreft, die tabjes, - maar ook per domain lijkt me maar niets,

ik had liever gezien dat er een mogelijkheid kwam om dat zelf te bepalen.

voorbeeld: youtube - rclick -> properties -> site prefs -> load page in its own process
of: extra -> browser propperties -> processes -> create new group -> *://*.tweakers.net

liever dat dan een of ander automatisch iets waar je verder weinig mee kunt,
bovendien zou je dan kunnen nagaan of en hoevaak iemand veel de zelfde sites tegelijk opeend (in verschillende tabs etc) - om na een gegeven aantal, aan te bieden deze verzameling voortaan in een appart process te laden.

[Verwijderd]

Ik snap niet waarom ze niet gewoon de cache van de tabs scheiden. Dat is helemaal niet zo moeilijk, en levert veel efficienter geheugengebruik op.

Voor de prestaties is het absoluut niet noodzakelijk dat cache in hetzelfde process draait als de tab. De functionaliteit van de cache is niet wezenlijk anders dan een ramdisk waarop je de tijdelijke internet files dumpt.

[Left]

Hoe zit het met die nieuwe snelle JavaScript engine, zit die ook al in 3.2 ?

[Maurits van Baerle]

Die komt in 3.1.

[Scapa Flow]

De nieuwe snelle Java script engine zal uitkomen met versie 3.1 (nu in Beta 2) en zal dus ook in 3.2 zitten

[David Mulder]

Prism elementen leent van Googles Chrome-browser

Ik heb geexperimenteerd vanaf het moment dat het nog webrunner heete en ik zou iedereen er toch ff willen op wijzen dat dat er vreselijk veel eerder was dan Google chrome...

[YopY]

Da's goed mogelijk, maar Chrome en Firefox gebruiken beide veel onderdelen van elkaar. Beide zijn open-source producten, en vooral Chrome is door Firefox beïnvloed. Het is goed mogelijk dat delen van Chrome's sandbox (Gears e.d.) beinvloed zijn door Prism.

[Scapa Flow]

Prism staat onder meer het starten van een applicatie op basis van een initialisatiebestand toe, en er wordt gewerkt aan het draaien van apps in hun eigen 'sandbox'. Dit zou niet alleen de veiligheid ten goede komen, maar het ook mogelijk maken om door het scheiden van cookies bijvoorbeeld met verschillende Google-accounts in te loggen.

Dit lijkt me goede toevoegen. In veel gevallen wanneer je bijvoorbeeld wilt switchen tussen een yahoo of google account moet je eerst uitloggen en weer in loggen voor de andere.

Meerdere account naast elkaar ingelogd hebben geeft dus tijds winst