mboost-dp1
Adobe
Det lægger sig jo meget op af Microsofts WPF & WPF/E framework (bl.a. silverlight) som blev introduceret i .NET 3.0
Det er jo godt nok med lidt konkurrence til MS, men ak hvor ville det være rart hvis de for en gangs skyld kunne gå sammen om at lave en standard, fremfor at man skal til at lære at udvikle i 2 forskellige miljøer hvoraf det kun vil være det ene der "vinder" i længden.
Det er jo godt nok med lidt konkurrence til MS, men ak hvor ville det være rart hvis de for en gangs skyld kunne gå sammen om at lave en standard, fremfor at man skal til at lære at udvikle i 2 forskellige miljøer hvoraf det kun vil være det ene der "vinder" i længden.
Det underholdende er lidt at man skal installere et runtime der på mange måder ER en browser, for at kunne downloade og afvikle en applikation der på mange måder ER en hjemmeside. Samtidig med det skal man iøvrigt acceptere en ond advarsel om at denne lokale hjemmeside kan tilgå lokale filer.
Beklager Adobe, men jeg har svært ved at tro på modellen med at afvikle hjemmesider som selvstændige applikationer og det vil ihvertfald aldrig overflødiggøre traditionelle browsere.
Beklager Adobe, men jeg har svært ved at tro på modellen med at afvikle hjemmesider som selvstændige applikationer og det vil ihvertfald aldrig overflødiggøre traditionelle browsere.
#5: Der er meget stor forskel på WPF og Silverlight og så det her AIR.
WPF er beregnet til traditionel applikationsudvikling, med alt hvad det indebærer - derudover kan det beskrives som en platform til generiske hardwareaccelererede (benytter DirectX) UIs i både 2D og 3D.
Skal AIR sammenlignes med noget er det nok Silverlight, men her anvender silverlight en hel anden strategi da det afvikles på traditionel vis via en almindelig browser - altså lidt som flash.
Det mest bemærkelsesværdige ved AIR er at de mener at man i fremtiden vil ønske at hente et helt website ned som en samlet pakke og afvikle det lokalt - for at opnå en eller anden form for sammensmeltning af web og traditionelle applikationer, hvilket jeg desværre må indrømme jeg ser som lidt af et flop (specielt efter at have afprøvet EBays AIR applikation i praksis).
WPF er beregnet til traditionel applikationsudvikling, med alt hvad det indebærer - derudover kan det beskrives som en platform til generiske hardwareaccelererede (benytter DirectX) UIs i både 2D og 3D.
Skal AIR sammenlignes med noget er det nok Silverlight, men her anvender silverlight en hel anden strategi da det afvikles på traditionel vis via en almindelig browser - altså lidt som flash.
Det mest bemærkelsesværdige ved AIR er at de mener at man i fremtiden vil ønske at hente et helt website ned som en samlet pakke og afvikle det lokalt - for at opnå en eller anden form for sammensmeltning af web og traditionelle applikationer, hvilket jeg desværre må indrømme jeg ser som lidt af et flop (specielt efter at have afprøvet EBays AIR applikation i praksis).
Det er jo en udvikling i den totalt modsatte retning af, hvad mange andre teknologier sigter mod for tiden. Personligt tror jeg, det er et spørgsmål om tid, før størstedelen af vores applikationer bliver afviklet på nettet, frem for den lokale maskine. Det er så meget lettere (givet MSIE, FF og de andre gutter selvfølgelig overholder standarderne) at udvikle webapplikationer som kan afvikles under alle OS og på alt hardware, end det er at udvikle flere applikationer til de forskellige styresystermer. Det gør desuden databehandling klienterne imellem herligt meget lettere..
Interessant valg Adobe, but I think its money down the drain..
Interessant valg Adobe, but I think its money down the drain..
#10
Sikke noget sludder - der findes da rigtig rigtig mange applikationer, der bliver afviklet på din PC, og bruger nettet til at kommunikere med.
Herinde er det mest åbenlyse at nævne spil - de afvikles som fede klienter ude hos brugeren, og sender så relevant information til en server.
En af de store problemer, ved at have servertunge applikationer, er naturligvis at du trækker heftigt på serveren, og jo flere der er online, jo kraftigere cluster skal du have til at servicere dine kunder.
Bag Sony's site: playstation.com står der mere end 100 applikations-servere, og når vi kommer op i en installation af den størrelse, så er det lidt uhensigtsmæssigt for serviceudbyderen.
Derfor er det temmelig interessant, at få flyttet workloadet ud hos klienten - der som oftest har mere luft til at afvikle applikationen.
Det er jo en udvikling i den totalt modsatte retning af, hvad mange andre teknologier sigter mod for tiden.
Sikke noget sludder - der findes da rigtig rigtig mange applikationer, der bliver afviklet på din PC, og bruger nettet til at kommunikere med.
Herinde er det mest åbenlyse at nævne spil - de afvikles som fede klienter ude hos brugeren, og sender så relevant information til en server.
En af de store problemer, ved at have servertunge applikationer, er naturligvis at du trækker heftigt på serveren, og jo flere der er online, jo kraftigere cluster skal du have til at servicere dine kunder.
Bag Sony's site: playstation.com står der mere end 100 applikations-servere, og når vi kommer op i en installation af den størrelse, så er det lidt uhensigtsmæssigt for serviceudbyderen.
Derfor er det temmelig interessant, at få flyttet workloadet ud hos klienten - der som oftest har mere luft til at afvikle applikationen.
#11: Det eneste load de reelt kan skære fra er vel de traditionelle webservere, da frontend-delen afvikles lokalt.
Applicationsserverne ændres der ikke så meget ved, dataene skal jo stadig hentes remotely og der skal stadig implementeres sikkerhed, validering osv osv på serversiden.
Til gengæld skal man så downloade hele frontenden første gang man vil besøge det, i E-bays tilfælde var det en pakke på lidt over 3 MB. Dvs. man skal istedet have nogle store download-servere parat, specielt når man udsender en opdatering og alle nu pludselig skal downloade alle 3 MB forfra på henad samme tid.
Jeg har svært ved at se at der er meget sparet ved den strategi, specielt når man tænker på hvor nemt det er at skalere frontend-load i et traditionelt setup - det er jo slet ikke her problemet normalt ligger.
Selvfølgelig har man flere muligheder for at lave nogle ting mere smart i en applikation der kan tilgå filer lokalt på brugernes disk og lign. Men er det sådan flexibilitet man er ude efter så banker eksempelvis en traditionel java-applikation nok det her AIR rimelig kraftigt. Jeg skal så ikke kunne sige om det er billigere på sigt at hyre AIR-udviklere, fremfor dygtige java-folk, da den eneste valide pointe jeg kan se er at indlæringskurven for diverse webteknologier nok er kortere - tilgengæld er det så noget af et teknologi-mix man skal have styr på for at kode AIR - hvor man med en java-applikation kan nøjes med at kode det hele i en og samme teknologi.
Applicationsserverne ændres der ikke så meget ved, dataene skal jo stadig hentes remotely og der skal stadig implementeres sikkerhed, validering osv osv på serversiden.
Til gengæld skal man så downloade hele frontenden første gang man vil besøge det, i E-bays tilfælde var det en pakke på lidt over 3 MB. Dvs. man skal istedet have nogle store download-servere parat, specielt når man udsender en opdatering og alle nu pludselig skal downloade alle 3 MB forfra på henad samme tid.
Jeg har svært ved at se at der er meget sparet ved den strategi, specielt når man tænker på hvor nemt det er at skalere frontend-load i et traditionelt setup - det er jo slet ikke her problemet normalt ligger.
Selvfølgelig har man flere muligheder for at lave nogle ting mere smart i en applikation der kan tilgå filer lokalt på brugernes disk og lign. Men er det sådan flexibilitet man er ude efter så banker eksempelvis en traditionel java-applikation nok det her AIR rimelig kraftigt. Jeg skal så ikke kunne sige om det er billigere på sigt at hyre AIR-udviklere, fremfor dygtige java-folk, da den eneste valide pointe jeg kan se er at indlæringskurven for diverse webteknologier nok er kortere - tilgengæld er det så noget af et teknologi-mix man skal have styr på for at kode AIR - hvor man med en java-applikation kan nøjes med at kode det hele i en og samme teknologi.
#14 det kommer vel an på, hvilken logik du ligger på din side.
Det er klart, at hvis det er almindelig web-logik, hvor der er lidt datavalidering, og skrivning/læsning til en database, så vil benefit være relativt begrænset - men ligger du tungere logik i dine applikationer vil det hurtigt kunne være en god investering.
Jeg kender intet til AIR, så at stille det op mod java afviklet i en browser har jeg ikke lyst til.
Min pointe er blot, at kan du flytte noget af det CPU-krævende fra din applikationsserver, til de klienter der kontakter dig - så vil du kunne reducere din serverfarm betydeligt.
Det er klart, at hvis det er almindelig web-logik, hvor der er lidt datavalidering, og skrivning/læsning til en database, så vil benefit være relativt begrænset - men ligger du tungere logik i dine applikationer vil det hurtigt kunne være en god investering.
Jeg kender intet til AIR, så at stille det op mod java afviklet i en browser har jeg ikke lyst til.
Min pointe er blot, at kan du flytte noget af det CPU-krævende fra din applikationsserver, til de klienter der kontakter dig - så vil du kunne reducere din serverfarm betydeligt.
#15: Jeg har endnu ikke set et eksempel på en AIR applikation der udførte tungere logik på klient-siden, de minder mest af alt om en hjemmeside forklædt som en applikation. Det er selvfølgelig muligt vi vil se det på sigt, men det virker bare ikke som værende formålet med AIR.
Og hvis du endelig vil udføre tungere logik på klienten, så skal du stadig hente dataene og sende resultatet tilbage, så medmindrer man har tænkt sig at lave noget ala Folding@AIR, så tror jeg der er meget få scenarier hvor det er virkelig relevant. For ikke at tale om at actionscript ikke ligefrem er det fedeste sprog at lave størrer matematiske beregninger eller tungere dataprocessering i, her vinder java helt klart også (hvis vi skal holde os til relativt platformsuafhængige teknologier) :-)
Jeg tror iøvrigt du misforstod mig lidt i forhold til Java, jeg tænkte ikke på Java applets, men derimod fullfledged Java applikationer der downloades og køres på klienten med lokale rettigheder, præcis som en AIR applikation.
Og hvis du endelig vil udføre tungere logik på klienten, så skal du stadig hente dataene og sende resultatet tilbage, så medmindrer man har tænkt sig at lave noget ala Folding@AIR, så tror jeg der er meget få scenarier hvor det er virkelig relevant. For ikke at tale om at actionscript ikke ligefrem er det fedeste sprog at lave størrer matematiske beregninger eller tungere dataprocessering i, her vinder java helt klart også (hvis vi skal holde os til relativt platformsuafhængige teknologier) :-)
Jeg tror iøvrigt du misforstod mig lidt i forhold til Java, jeg tænkte ikke på Java applets, men derimod fullfledged Java applikationer der downloades og køres på klienten med lokale rettigheder, præcis som en AIR applikation.
#16 nu kender jeg som sat ikke noget til AIR, men du har ret i - at hvis de giver mulighed for det samme, som en fullfledged java så er svært at få øje på de store benefits.
Mit indlæg #11, var primært en refklektion over #10, der mener at klienter med lidt tyngde er uddøene. Jeg mener at man bygger op på begge sider - altså gør appliaktionsservere mere funktionelle, så man kan afvikle rigtig tunge applikationer der, men omvendt synes jeg også der er tendens til fede klienter...
Mit indlæg #11, var primært en refklektion over #10, der mener at klienter med lidt tyngde er uddøene. Jeg mener at man bygger op på begge sider - altså gør appliaktionsservere mere funktionelle, så man kan afvikle rigtig tunge applikationer der, men omvendt synes jeg også der er tendens til fede klienter...
Det var dog utrolig så kritiske folk er overfor dette.. Synes personligt det virker bedre end så meget andet 3. parts software. Det er lightweight, i modsætning til Java, som jeg personligt synes er noget værre lort pga. installationen og de resourcer det kræver. AIR er et fint program der er godt fundet på, der er rigtig mange hjemmeside udviklere som gerne vil have noget lign. AIR så de kan bruge deres erfaringer til at afvikle noget på klient siden. Et fint eksempel på et program er beatport downloader, som både har været ude til AIR Beta 1 og Beta 2.. Må sige at det virker meget bedre end de tilsvarende programmer lavet i Java fra andre hjemmesider med samme formål. Det der er smart er at der indbygget en organiserings funktion i programmet, som man ikke kan lave med online funktioner, ergo er AIR smart.. Tror sagtens der er fremtid i det her program, også selvom om i hvert fald 5 år bliver mere online baseret.
#17: Jo, jeg er da enig i at det her med tynde klienter ikke er en god løsning i alle tilfælde, men ja, jeg er ikke ligefrem overbevist om at det her er sønderligt velegnet til at lave tykkere klienter i - sammenlignet med eksisterende teknologier på markedet til det formål, herunder Java og .NET.
#18: Når Adobe melder ud at den traditionelle browser er død (medmindrer det bare var en comon-overskrift), så tillader jeg mig at være skeptisk :)
Jeg har svært ved at se det virkelig revolutionerende i det her, specielt hvis man er applikations-udvikler i forvejen.
Der hvor det måske kan have sin berettigelse er at deciderede webudviklere, måske nemmere kan lave noget der minder om en applikation (såfremt de altså har styr på det her hav af teknologier der udgør en AIR applikation). Jeg har iøvrigt svært ved at se dette som værende lightweight - Javascript, HTML, Flash og lign. er jo ikke ligefrem lightweight teknologier og snakker vi størrelsesmæssigt så finder jeg heller ikke 3 MB for et program til at browse E-bay som værende sønderligt imponerende.
Men altså, hvorfor skulle vi dog ønske at benytte os af HTML, CSS, Javascript, Flash, Ajax og lign. besværlige webteknologier til traditionel applikations-udvikling også - det er da bare at begrænse egne muligheder og gøre det mere besværligt for os selv. Tag en WPF-applikation eksempelvis, her kan hele UI'en håndteres i én og samme teknologi og dine UI muligheder er tilmed så powerfulde at vi her reelt kan tale om lidt af en revolution, sammenlignet med traditionel UI udvikling - her kan sådan noget som AIR jo slet ikke følge med. WPF har tilgengæld den ulempe at det ikke er sønderligt platformsuafhængigt, hvilket er grunden til at jeg i mine tidligere indlæg har fremhævet Java istedet - men det afhænger så af ens målgruppe og formålet med applikationen om det er et problem eller ej.
#18: Når Adobe melder ud at den traditionelle browser er død (medmindrer det bare var en comon-overskrift), så tillader jeg mig at være skeptisk :)
Jeg har svært ved at se det virkelig revolutionerende i det her, specielt hvis man er applikations-udvikler i forvejen.
Der hvor det måske kan have sin berettigelse er at deciderede webudviklere, måske nemmere kan lave noget der minder om en applikation (såfremt de altså har styr på det her hav af teknologier der udgør en AIR applikation). Jeg har iøvrigt svært ved at se dette som værende lightweight - Javascript, HTML, Flash og lign. er jo ikke ligefrem lightweight teknologier og snakker vi størrelsesmæssigt så finder jeg heller ikke 3 MB for et program til at browse E-bay som værende sønderligt imponerende.
Men altså, hvorfor skulle vi dog ønske at benytte os af HTML, CSS, Javascript, Flash, Ajax og lign. besværlige webteknologier til traditionel applikations-udvikling også - det er da bare at begrænse egne muligheder og gøre det mere besværligt for os selv. Tag en WPF-applikation eksempelvis, her kan hele UI'en håndteres i én og samme teknologi og dine UI muligheder er tilmed så powerfulde at vi her reelt kan tale om lidt af en revolution, sammenlignet med traditionel UI udvikling - her kan sådan noget som AIR jo slet ikke følge med. WPF har tilgengæld den ulempe at det ikke er sønderligt platformsuafhængigt, hvilket er grunden til at jeg i mine tidligere indlæg har fremhævet Java istedet - men det afhænger så af ens målgruppe og formålet med applikationen om det er et problem eller ej.
Personligt synes jeg at det der er ved at ske mht. online-apps, etc. er en meget spændende udvikling.
Lige præcis mht. AIR, her, er jeg lidt nervøs for at det viser sig at blive en gang "varm luft" ;0p
Lige præcis mht. AIR, her, er jeg lidt nervøs for at det viser sig at blive en gang "varm luft" ;0p
Så nu skal vi overlade interfacet til vores Web.adgang til Adobes nåde. Et firma der benytter enhver chance for at proppe DRM ind under vores motorhjelm.
Hvis de ikke ønsker at understøtte en specifik platform er denne prisgivet - hvorledes ser historikken nu ud for deres multiplatformsprodukter ?
Ja Windows har hele tiden haft fuld understøttelse, MacOS X næsten fuld understøttelse. Med de resterende er det som vinden blæser.
Jeg kan huske da eCS-samfundet ville portere Flash-6/7, der gjorde Adobe deres bedste for at spænde ben og det ellers færdige plugin blev aldrig udgivet - NDA eller ikke NDA.
Nej aldrig i livet - Adobe er som en politker, når de ikke er ude for at kysse små børn, stjæler de deres slikkepind.
Så hellere noget Java Web Start stads, der vist fungerer på nogenlunde samme måde - jeg har større tiltro til SUN.
Hvis de ikke ønsker at understøtte en specifik platform er denne prisgivet - hvorledes ser historikken nu ud for deres multiplatformsprodukter ?
Ja Windows har hele tiden haft fuld understøttelse, MacOS X næsten fuld understøttelse. Med de resterende er det som vinden blæser.
Jeg kan huske da eCS-samfundet ville portere Flash-6/7, der gjorde Adobe deres bedste for at spænde ben og det ellers færdige plugin blev aldrig udgivet - NDA eller ikke NDA.
Nej aldrig i livet - Adobe er som en politker, når de ikke er ude for at kysse små børn, stjæler de deres slikkepind.
Så hellere noget Java Web Start stads, der vist fungerer på nogenlunde samme måde - jeg har større tiltro til SUN.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund