Nieuwe webtaal Curl probeert internet te versnellen

Aangezien nog steeds niet iedereen een breedband internetverbinding heeft, proberen velen mogelijkheden te vinden om het wereldwijde web sneller te maken. In plaats van het opvoeren van de daadwerkelijke bandbreedte, hebben onderzoekers van het Massachusetts Institute of Technology (MIT) het gezocht in de code die verstuurd wordt om webpagina's weer te geven op de computer van de internetter. Een oplossing voor het snelheidsprobleem is volgens hen de plugin Curl, geproduceerd door het door de onderzoekers opgerichte Curl Corporation.

De werking is even simpel als doeltreffend, als we tenminste mogen geloven wat er allemaal beweerd wordt. De mensen van het MIT zijn er van overtuigd dat het binnenhalen van websites traag gaat, doordat van verschillende programmeertalen gebruik gemaakt kan worden. Hierbij gaat het vooral om het eenvoudige HTML en het ingewikkeldere Java. Het samensmelten van deze twee basisleggers van het huidige internet is noodzakelijk, aldus het hoofd van Curl Corporation.

Curl zal de talen HTML en Java kunnen vervangen, door middel van een plugin: Surge. Wie dit stukje software geïnstalleerd heeft, krijgt toegang tot de nieuwe techniek die zich uitstrekt van zeer eenvoudige tekst tot complexe driedimensionale toepassingen. Met name de uitgebreidere internet-applicaties op Java-applet niveau, zullen tot maar liefst tien keer zo snel binnengehaald kunnen worden. Hoe men een dergelijke reusachtige verbetering tot stand heeft gebracht wordt niet helemaal duidelijk, het lijkt tenminste haast ondenkbaar dat alleen de code-samensmelting een dermate grote versnelling met zich mee zou brengen.

Het probleem dat bij een nieuwe ontwikkeling altijd lastig op te lossen is, betreft de financiële kant van de zaak. Het plan is om bedrijven een kleine vergoeding te laten betalen voor elke internetter die iets in het Curl-formaat downloadt, maar of dit de populariteit ten goede zal komen is natuurlijk af te vragen. Zeker gezien het feit dat er een groot aantal gratis varianten zijn, zullen niet veel bedrijven zich tot Curl wenden, zo denkt Edd Dumbill van XML.com. Zoals ik al wel vaker gezegd heb: de toekomst zal het uitwijzen.

Batser wees ons als eerste op dit verhaal van WebWereld, maar wie liever de Engelse variant leest kan bij New Scientist terecht.

Reacties (40)

[BurningSheep]

Ik heb hier een beetje m'n twijfels over, volgens mij is het probleem eerder dat er grote grafische files mee worden gestuurd. Ben eigenlijk wel benieuwd wat de gemiddelde verhouding tussen tekst en graphics is qua gedownloade bytes op een gemiddelde pagina

[memphis]

Klopt helemaal, steeds meer sites worden grafisch opgebouwd, achtergrondjes, grafische menu's etc maar ook Flash.
Text georienteerde sites lopen zelfs via mijn GSM snel binnen.

En wat compressie betreft, veel modems maken daar hardwarematig al gebruik van

[0rbit]

Uhm... Aangezien JAVA-code voornamelijk bestaat uit een klein deel van alle ASCII tekens uit de tekenset blijft er genoeg ruimte over om met de andere tekens een vorm van compressie tot stand te brengen. (Dat is de reden dat tekstfiles zo goed comprimeren)

Dat hoort toch al minstens een factor 5 te schelen...

[mbravenboer]

Java gebruikt Unicode, maar dat terzijde...

Java applets (en die nieuwe Java Webstart applicaties) kunnen gedistribueerd worden als Java Archives (jar bestanden). Dit zijn in feite gewoon zip bestanden, die optioneel ook gecomprimeerd kunnen worden. Bovendien kan je Java code ook nog 'obfuscaten', waardoor alle variabele en klasse namen vervangen worden door korten namen zoals A, AZ, T etc. Dit zorgt ervoor dat klassen extreem klein worden.

Het probleem van Java is in ieder geval niet de grootte van de applicaties, maar de gedegen technische kennis die je nodig hebt om een redelijke applet of Java webstart applicatie te kunnen schrijven.

[Ritch]

Java applets zijn gecompiled enzo, dus machinetaal, dus voor java zal dat niet opgaan, html wel

[deviltje]

Java en machinetaal zijn niet echt te vergelijken he.. Oke het ding dat het vertaald naar iets wat je compu begrijpt heet een virtual machine.. maar die vertaal slag duurt echt super lang... als bij surge dit neit het geval is, dan kan het misschien een suc6 worden

[Verwijderd]

Heb jij zeker een P4 want op mijn Athlon-1.33MHz duurt het nog geen seconde (Opera met Java-plugin 1.4)...

(ok ok flame/troll/etc maar ik kon deze voorzet niet laten schieten )

Btw, een browser die goede java-support heeft, kan zgn. JAR (Java-ARchives) downloaden waarin de applet zit, ipv de losse (ongecompressed) binaire class-files; JAR is feitelijk gewoon een ZIP-bestand.
Ik kan me niet voorstellen dat ze dat nog heel veel verder zouden kunnen compressen. Evenals de jpg's etc., zie daar nog maar eens wat vanaf te krijgen.

Ook HTML kan allang gecompressed worden overgestuurd, maar het is weer het bekende verhaal van de standaards: niet alle browsers en webservers supporten het, en dus blijft het merendeel nog gewoon ongecompressed verstuurd worden.

Weer een nieuwe webtaal erbij zal de acceptatie echt niet beter maken...

[SvMp]

de flessehals zit in de transfer, niet in de interpretatie van die Java bytecode, dankzij al die snelle bakken van tegenwoordig..

[deviltje]

Helaas zit het in allebei.. als jij voor de 1e keer je VM gaat opstaarten ben je bijna een minuut bezig zelfs op je 1.4GHZ machine

[markvt]

krijgen we dan zip sites, die realtime gedecompresseerd worden en dan bekeken, zo staat het er volgens mij

[Verwijderd]

zoiets als "zip sites" bestaat al erg lang (sinds HTTP versie 1.1)

je kunt je sites gewoon laten compressen door php bijvoorbeeld, maar ook door apache zelf.. erg handig, en je page downloads worden gemiddeld 3 keer zo klein (die factor 3 is mijn eigen bevinding in ieder geval)

[henk jansen]

hehe dan is dus weer toekomst voor mij?

trekt namelijk wel wat processor kracht maar die heb ik wel. ik heb alleen een modempie. dus voor mij is dit zeker aantrekkelijk. trouwens ook voor de rest van de internettters. minder data is meer snelheid

[Johannes]

En dit wordt ook al onder andere gebruikt, o.a. op Got.(behalve wat probleempjes met Opera daarmee dan, maar toch)

Factor 3 klopt in mijn testjes niet, de compressie ratio ligt bij het board waar ik zelf mee bezig ben zo rond de 50%, dus factor 2, waar dan nog wel extra processortijd vanaf gaat.

[DeuTeRiuM]

Als je in je profiel kijkt, zie je dat tweakers.net en got ook gecompressed overgebracht worden(werden?). Er staat namelijk een optie of je de pagina's wel of niet gecompressed wil binnenkrijgen.

[mvds]

Ik denk dat dit wel een tidjelijke oplossing zal zijn. Niet iedereen heeft een breedband verbinding, maar hoelang zal dat nog zo zijn? Internetcontent word steeds mooier en zal dus steeds meer bandbreedte nodig hebben. Dan kan je dit soort compressies gaan ontwikkelen (en dat is heel mooi natuurlijk) maar op een gegeven moment trekt je ISDN lijntje het gewoon niet meer en dan zal je wel naar een breedbandverbinding toe moeten. Net zoals je niet eeuwig op een 486 zal kunnen blijven draaien.

Maar natuurlijk wel een mooie ontwikkeling.

[Verwijderd]

Het verleden heeft al meerdere malen laten zien dat de wensen van gebruikers minstens zo hard groeien als de ontwikkelingen. Ookal lijkt het nu ver weg, binnen niet al te lange tijd komen er toepassingen die meer bandbreedte vergen dan de huidige technieken (ADSL of kabel) zonder compressie kunnen bieden.

Verder kun je zeggen dat alle ontwikkelingen tijdelijk zijn, aangezien ze stuk voor stuk erg snel verouderen.

[mbravenboer]

Volgens mij maken ze hier toch een kleine vergissing. Het grootste probleem van de meeste websites is het grote gebruik van afbeeldingen in de layout. Dit zorgt er juist voor dat het lang duurt voordat pagina's geladen zijn. Het downloaden van HTML bestanden of Java applets is absoluut niet de bottleneck naar mijn mening. Hoe fantatisch Curl ook zal zijn, een groot deel van de content zal nog steeds uit afbeeldingen bestaan.

Gezien de huidige ontwikkeling op het gebied van XML en XSL lijkt deze techiek mij ook tamelijk kansloos. XML is unaniem gekozen tot de toekomst van data uitwisseling op het web. Met de huidige opkomende ondersteuning van XSL in de meest gebruikt browsers, zullen er binnen de kortste tijd veel pagina's zijn die XML en XSL gebruiken.

Curl zal bovendien nogal een complicerende factor zijn. Iedereen kan HTML schrijven (ok, iedereen denkt dat ze dat kunnen ). Curl is een echte programmeertaal. Het grootste deel van de pagina;s het web is denk ik geschreven door niet informatici die niet kunnen programmeren. Een taal als Curl is voor deze mensen geen alternatief. De echte programmeurs pakken wel Flash of Java applets/webstart voor een applicatie waarvoor HTML niet voldoet. Flash bestanden zijn overigens ook zeer klein.

[Beaves]

Curl zal de talen HTML en Java kunnen vervangen, door middel van een plugin: Surge. Wie dit stukje software geïnstalleerd heeft, krijgt toegang tot de nieuwe techniek die zich uitstrekt van zeer eenvoudige tekst tot complexe driedimensionale toepassingen. Met name de uitgebreidere internet-applicaties op Java-applet niveau, zullen tot maar liefst tien keer zo snel binnengehaald kunnen worden. Hoe men een dergelijke reusachtige verbetering tot stand heeft gebracht wordt niet helemaal duidelijk, het lijkt tenminste haast ondenkbaar dat alleen de code-samensmelting een dermate grote versnelling met zich mee zou brengen.

Ik heb een paar vragen, de server moet Curl dus ook hebben draaien neem ik aan, en ik zou als serverbeheerder niet zomaar een plugin installeren die helemaal niet getest is op bugs of andere dingen en helemaal niet een vage plugin die belooft dat internet sneller wordt.

Verder vraag ik me af hoe die plugin dan werkt, vertalen ze alleen Java code naar een andere of gebruiken een of andere compressie? (Verder ligt de snelheid van een pagina ook af van hoe goed Java geimplementeerd is in het gebruikte OS. (OS X van Apple bijvoorbeeld voerd Java suppersnel uit doordat het in het OS zit gebakken).

Als laatste vraag ik me af hoe ze met PHP, Coldfusion etc omgaan, want dat neemt steeds meer de plaats van Java in. (Vergeet ook C# in de toekomst niet). Hoe gaat die plugin met die data om en heeft de gebruiker daar ook iets aan.

Als laaste punt lijkt me het helemaal niet handig om meteen geld te vragen, kunnen ze beter mee wachten totdat de plugin zich echt vast heeft bewezen en dat daardoor mensen graag willen betalen voor iets wat echt blijkt te werken.

[Verwijderd]

Ik heb een paar vragen, de server moet Curl dus ook hebben draaien neem ik aan, en ik zou als serverbeheerder niet zomaar een plugin installeren die helemaal niet getest is op bugs of andere dingen en helemaal niet een vage plugin die belooft dat internet sneller wordt.

Zoals ik het lees is het een vervanging van HTML, Java en javascript ed. Dus is het gewoon een tekstbestand op de server, die clientside verwerkt wordt (net als HTML nu).

Verder vraag ik me af hoe die plugin dan werkt, vertalen ze alleen Java code naar een andere of gebruiken een of andere compressie? (Verder ligt de snelheid van een pagina ook af van hoe goed Java geimplementeerd is in het gebruikte OS. (OS X van Apple bijvoorbeeld voerd Java suppersnel uit doordat het in het OS zit gebakken).

Omdat de taal minder content vereist wordt het dus sneller. Compressie zit zowieso in http 1.1 dus daar hoef je niet voor te switchen. Het OS is niet van toepassing omdat het hier om een bandbreedte verhaal gaat, niet over verwerkingstijden op iemands compu.

Als laatste vraag ik me af hoe ze met PHP, Coldfusion etc omgaan, want dat neemt steeds meer de plaats van Java in. (Vergeet ook C# in de toekomst niet). Hoe gaat die plugin met die data om en heeft de gebruiker daar ook iets aan.

Als curl ook tekstbased is, dat zal wel, dan kunnen talen als ASP, PHP en Coldfusion hier in principe wel mee overweg. Je genereert gewoon content in een andere taal.
Ik weet niet wat je bedoelt met de plaats van Java innemen, want Java en ASP/PHP dat zijn compleet andere dingen.

Als laaste punt lijkt me het helemaal niet handig om meteen geld te vragen, kunnen ze beter mee wachten totdat de plugin zich echt vast heeft bewezen en dat daardoor mensen graag willen betalen voor iets wat echt blijkt te werken.

Het is een fors project en ze zullen het geld hard nodig hebben, maar ik ben het wel met je eens. In een www wereld waar iedere nieuwe standaard gratis open source is is dit wel erg ouderwets.

Ik verwacht eerlijk gezegd hier voorlopig niet zo veel van. HTML is gewoon niet weg te denken, en de getallen die ze hier noemen zullen alleen gelden voor speciale toepassingen, die zeker niet vaak voor zullen komen. Als je er dan ook nog voor moet betalen dan hoeft het denk ik al helemaal niet meer...

[jkf]

Waarom zou de server ook Curl moeten hebben draaien? De webpaginas moeten in curl op de server staan, de server moet misschien zelfs de juiste content type meegeven, maar daar is (in ieder geval bij Apache) geen plugin voor nodig. PHP neemt niet de plaats in van Java applets, PHP is meer vergelijkbaar met Java servlets, normaal gesproken genereren PHP en Java servlets HTML (of WML). Een grotere vraag is kunnen die dat Curl spul genereren op een beetje handige manier.

[Verwijderd]

ik mag toch hopen dat ze 't over javascript hebben en niet over java

wat de fuck boeien applets nou ?

aan de andere kant, misschien ist handig als er een "open source" (als html) achtige taal komt die alles kan...

[mbravenboer]

wat de fuck boeien applets nou ?

Applets worden veel gebruikt voor chat-applicaties, online games, online bankieren enz. Bovendien draaien er op intranets van bedrijven ook zeer veel nuttige applets.

[TheGhostInc]

Op Intranets heb je weer vaak GEEN bandbreedte probleem, eerder een server probleem (teveel applicaties op een server).
Daarnaast zijn het echt niet de html tekst die het probleem vormen, het gaat dan meer op jpg's maar tegenwoordig ook steeds meer mp3/divx daar kun je niks meer aan doen qua compressie (niet op deze manier)

[Verwijderd]

Zoals ik het lees is het een hele nieuwe web/scripting taal. Dit zou dus betekenen dat je weer helemaal opnieuw moet beginnen om alles te leren, lijkt mij niet echt handig.

Aan de andere kant als het mogelijk makkelijker en sneller is. Dan zou het met name voor newbie leuker zijn. Verder zou je het gezeur niet hoeven hebben van IE beeld me pagina goed af en NN niet.

Alleen blijf je ermee zitten dat 50% van de gebruikers IE gebruikt zoals het in windows zit en geen plug-ins gaat downloaden

[deviltje]

Vanaf ie5 is M$ ook al bezig een compleet nieuwe taal te introducen op internet genaamd SMIL.. dit is absoluut geen standaard, maar is absoluut gedoeld op het verdrijven van zowel java als flash, omdat er nogal heel simpel animaties mee gemaakt kan worden..

en neimand zal dit tegen gaan houden juist om jouw argument... dus argument spreek zich zelf al tegen...

[mbravenboer]

SMIL is wel degelijk een standaard. Kijk maar eens op de front-page van de w3c site http://www.w3c.org

9 August 2001: The World Wide Web Consortium today released the Synchronized Multimedia Integration Language (SMIL) 2.0 as a W3C Recommendation. The specification has been reviewed by the W3C Membership, who favor its adoption by industry. SMIL (pronounced "smile") defines an XML-based language that authors can use to write interactive multimedia presentations. Version 2.0 includes approximately one hundred predefined transition effects, and support for hierarchical layout and animation. See how SMIL is already implemented, and read the press release and testimonials.

[Aaargh!]

De mensen van het MIT zijn er van overtuigd dat het binnenhalen van websites traag gaat, doordat van verschillende programmeertalen gebruik gemaakt kan worden.

ze zeggen dus dat het internet zo traag is omdat er zo veel verschillende talen zijn, en wat doen ze ... NOG een taal bedenken

trouwens wel een vage bewering, want het downloaden van verschillende talen gaat echt niet langzamer dan allemaal dezelfde. de bottleneck zit dan eerder aan de clientside (JVM starten enzo) maar dat probleem blijf je houden want nu moet de CURL plugin gestart worden.

[mbravenboer]

JVM starten enzo

Binnen afzienbare tijd gaat Java een ander execute proces gebruiken, waardoor de starttijd van de VM minimaal wordt.

Allereerst zal er VM Sharing worden geimplementeerd waardoor de code van de Java bibliotheken gedeeld wordt door alle VM instanties. Dit beperkt gigantisch het geheugengebruik, maar ook de opstarttijd.

Later zal er ook een oplossing komen waardoor alle Java applicaties in 1 VM worden gestart. Hierdoor kan je de VM starten als de computer start (zoals dus bij IE en Mozilla/Netscape quick-launch gebeurt). Het starten van Java applets of Java applicaties zal daarna razendsnel gaan.

[RM-rf]

cUrl lijkt me wel een specifieke interessante doelgroep gevonden te hebben; mobiele telefoons,
zowel Siemens als wat andere duitse mobiele telefonie-bedrijven (adisoft AG) hebben al contracten afgesloten.

gezien de snelheids-problemen daar en het gebrek aan veel echte content liggen daar meer mogelijkheden:
ook de bestaande applicaties in WML kunnen redelijk eenvoudig overgezet worden aangezien cUrl ook XML-based is.

edit: sorry dat heb ik fout; cUrl is niet XML-based, maar kent een soort van methode om scripting te includen in platte tekst als markup, compleet incomp. met XML (tags tusen {} brackets), er zijn echter wel al een aantal dev-tools die gemakelijke integratie van xml in cUrl documenten mogelijk maken.

misschien wijst dat op een zwakte van java, hoewel java zer veel nut heeft met xml-parsing en rendering kent java zelf geen eigen xml-interface (ook niet direct nodig vanuit een idee van een virutal machine maar voor developpers kan dat best handig zijn een verder uitgewerkt scripting platform met interfaces naar andere data-types)
/edit

juist de xtra mogelijkheden met java-like applicaties maken dit interessant.

voor het bestaande worldwideweb is er weinig kans dat curl erg aan zal slaan: XHTML en zeker de laatste modulaire opzet hiervan is veel breder en geaccepteerder. gzip-http lost daar de laadtijd wel op (bedenk wel dat gzipped http op snelle verbindingen als T1 nauwelijks voordeel biedt en soms zelfs langzamer kan werken)

overigens is de plugin nog windows only, linux en mac moeten nog ontwikkeld worden (is men mee bezig)

[mbravenboer]

kent java zelf geen eigen xml-interface

Ik weet niet precies waar je op doelt met een XML interface, maar Java biedt vrijwel alles wat je maar kan bedenken. Met JSP is het mogelijk om naast (X)HTML bijvoorbeeld XML data op te leveren, waardoor je dus een eenvoudige, maar krachtige manier hebt om data te combineren met Java code. Verder biedt Java ronduit uitstekende mogelijkheden om XML te parsen of nieuwe XML documenten te maken. Al tijden is JAXP beschikbaar. In combinatie met de Xerces XML parser van Apache heeft het Java Platform hiermee een uistekende XML parser tot zijn beschikking. In het Java 2 Platform v1.4, die later dit jaar zal uitkomen, zal JAXP standaard opgenomen zijn. Hierdoor kan elke Java VM zowel XML parsen als XSL stylesheets toepassen.

1.4 zal ook voorzieningen bevatten om Java Beans te serializeren naar XML en andersom.

[RM-rf]

ik ken zelf AElfred, een lichtgewicht, redelijk volledige XML-parser die voor client-java zeer geschikt is, meen iets van 35Kb;
echter ik neem aan dat cUrl al een in de plugin ingebouwde xml-parser heeft, als de laadtijd voor dat soort zaken bespaart wordt scheelt dat al zeer.

We hebben het nu juist over client-side, zeker voor ebanking applicaties kan dat interessant zijn, maar ook neem ik aan dat mobiele device-fabrikanten deze plugin standaard op hun devices kunnen gaan installeren, althans dat zal de doelstelling zijn van cUrl mbt hun contracten met deze fabrikanten.

[Verwijderd]

Dit wordt dus niks,
Al was het alleen maar omdat je als consument moet betalen voor het binnenhalen van een document.

Curl = dus client-side?