Názory k článku Akta X 0311

Vyznamny je take fakt, ze pro XUL jiz aplikace vznikaji, kdezto Avalon tu bude kdovi kdy. Navic mozilla je multiplatformni, takze takova webova aplikace bude dostupnejsi. Na druhou stranu, Avalon asi umozni mnohem lepsi vyuzivani moznosti a schopnosti windows, coz zrejme umozni vytvaret aplikace, ktere v XUL mozne delat nebude. Zajimave bude, jak se MS popere s bezpecnosti.

problem je ze naprosta vetsina vyvojaru pod Win povazuje slovo "multiplatformni" za anachronismus.. vim z vlastni zkusenosti... multiplatformnost se u win aplikaci neresi - dyt to STEJNE pobezi pod WINDOWS, tak co, ze :(((

<flame>Ano. Za příjemné uživatelské rozhraní přenositelnost rád obětuji ;))</flame>

QT? wxWindows? Java?

a kolik lidi to pouziva? V kazdy firme ktera jede pod windows tohle bud nikdy neslyseli a nebo nechapou proc to pouzivat kdyz maj ukradeny nejnovejsi MS visual studio kde se to da tak hezky snadno naklikat... a navic stejne 99,99% uzivatelu bude mit windows, tak co .. :((((

Nejsem si jist, jestli Java (QT a wxWindows jsem videl jen z rychliku) ma uzivatelske rozhrani definovane pomoci XML.

Jediny me znamy GUI toolkit pro Javu, ktery pouziva XML pro popis jsou ThinLets (http://thinlet.sourceforge.net/)

Pokud znate nejake dalsi, ktere jsou pouzitelne, tak dejte vedet. Zda se mi ze Java potrebuje takovyto XML toolkit jako sul a nejlepe standardni (JCP).

Tom

V dnesni dobe pronest takovouhle vetu - to neni moc pekna vizitka. Uprimne verim, ze slo jen o vtip, protoze pokud skutecne existuji takto smyslejici "programatori", nezbyva mi nez se ptat kam to lidstvo speje a doufat, ze vas zamestna nekdo jako Microsoft.

aspon podle mejch zkusenosti je tehlech lidi vetsina..

<cite><flame>Ano. Za příjemné uživatelské rozhraní přenositelnost rád obětuji ;))</flame></cite>

To je dost hloupe flame, kdyz multiplatformni mozilla nabizi o nekolik trid lepsi UI nez IE :-)).

To je skutecne vyjimecne stupidni odpoved. Nikdo vas nenuti vymenit prenositelnost ci multiplatformnost za kvalitni UI, pokud to nekdo tvrdi, vetsinou je to jeho lenost nebo neznalost veci.

Mimochodem, pokud mluvite o prijemnem uzivatelskem rozhranni, tak to snad windows vylucuje, ne ;) ?

> Mimochodem, pokud mluvite o prijemnem uzivatelskem rozhranni, tak to snad windows vylucuje, ne ;) ?

To bych se hádal :) Qt, GTK a podobné vymyšlenosti za příjemné rozhodně nepovažuju. Javovské GUI (myšleno to ze Swingu, samosébně) je velmi dobré, ale neuvěřitelně nenažrané. Existuje vůbec hardwarová sestava, na které by běželo plynule? :) XUL jsem neviděl, takže už mlčím.

Btw, ten příspěvek o výměně přenositelnosti za příjemné GUI jsem psal poněkud opilý :)))

Nevylučuje, dokonce podporuje i MDI...

:(((( takze po tom co konecne ne-MS svet dostal prohlizec srovnatelnej (nebo i lepsi) s IE, kancelarskej balik kterej uz skoro precte vsechny MS formaty, MS strikes back a diky avalonu zase budu s linuxem jako kul v plote.. ach jo.. avalon zcela urcite nebude znamenat konec web-u ale urcite to posili pozici MS na poli desktopu, kde stejne dominuje... vetsi nastup ne-MS desktopu se zase oddaluje na neurcito :(( je mi z toho smutno

No, vzhledem k datu vydani Longhornu (2-3 roky) a vzrustajici nechuti i velkych spolecnosti vuci posilovani monopolu Microsoftu (viz relativne velke fiasko s Licencing 6.0), tak doufam, ze snaha tlacit Avalon bude kontraproduktivni a povede k vetsimu rozsireni Mozilly a podobnych.

V jednom odstavci se pise:

HTML je sice pro tvorbu plnohodnotneho GUI prilis chude, ale uz nejaky cas tady mame Mozillu a jeji XUL.

A hned v tom dalsim:

Zatimco Mozilla stavi na standardech jako XHTML, CSS ci SVG, Microsoft vsechny tyto technologie, na jejichz vyvoji se sam podili, nahrazuje v Avalonu svymi proprietarnimi formaty.

Takze co teda? Stavi Mozilla na standardech anebo ma vlastni proprietarni format (XUL)? Protoze Microsoft taky stavi treba na SVG, akorat to rozsiril o veci co v nem nejsou (asi jako XUL umoznuje veci ktery v existujicich standardech nejsou). Sam autor uznava ze stavajici technologie sou na UI trochu strohe...

Podstatne horsi utok na standardy mi prijde vliv IBM na XML 1.1 kdy si kvuli proprietarnim white space znakum na mainframech vynutili nekompatibilni zmenu do XML standardu.

To si neodporuje, mozilla stavi na css, js, dom a dalsich znamych standardech. Protoze pro aplikacni UI zadny vhodny standard neexistoval, prisel se svym, XUL (postavenem na standardu XML), ktery s stavajicimi standardy umne propojil. Vyvojari mozilly tak pristoupili k nejmensi mozne, ale nutne, zmene.

Pokud by ses oba formaty podival, tak uvidis, ze Mozilla tak, kde se nabizelo vhodne reseni postavene na standardech ho pouziva a pridava jen veci, ktere na nich postavit nesly.

Takovy Avalon to vcelku ignoruje a jede si ve svych kolejich.

Tak dooost. Ja myslim ze je to predevsim tak, ze co udela Microsoft, je pro nektere lidi spatne naprosto od pocatku.

Avalon bude, pokud ho daji dohromady podle soucasnych nacrtu, moc pekna vec. Mam pocit, ze vetsina diskutujicich tady na rootu uz tak dva tri plne vektorove rendering enginy napsala, protoze naprosto presne vi, ze by SVG nebo XUL splnily ostre pozadavky na podobnou hracku jako mavnutim proutku.

Neni to spis tak, ze pokud uspesnost Longhornu bude do velke miry zaviset na fungujicim Avalonu a na slusnych API pro jeho pouziti, jen maloktera spolecnost by riskovala adoptovani cizich (byt "standardnich") technologii?

Copak byl XUL navrhovany jako format, ktery by mel byt pouzitelny pro rendering kompletniho obsahu obrazovky operacniho systemu? A SVG?

T.

XUL jiz je pouzivan pro cely desktop v HomeBase http://www.oeone.com/products/ (upravena Red Hat distribuce s desktopem postavenym na Mozille)

Videl jsem to ted poprve, ale porad je to podle meho nazoru jina liga nez [by mel byt] Avalon.

T.

m$ nema chut platit za dalsie web-rozhranie,preto placa o neexistencii web-browsera

Este by som chcel vidiet spolocnosti ktore prevadzkuju ako web apacha (cize cca 9x %), ako zahadzuju komplet odladene systemy a prechadzaju na nejake uzasne megalomanske uzavrete sracky a la microsoft. Je uplne jasne ze ten projekt padne do zabudnutia, ani sa nestihne poohriat.

Jsem rád, že aspoň nekřičíte, že XAML Microsoft neokopíroval od XUL Mozilly.

U takových jako vy člověk nikdy neví....;-)

Zato ty ses pruhlenej, jedna basen :-)))))))

...Microsoft připravuje zajímavé a technicky vyspělé řešení, které však bohužel opomíjí prakticky


Avalon vychází z XAML W3C recommendation. Pochybuju, že XUL Mozilly byl nějak standardizován v době, kdy Mozilla vznikala a že by jeho funkcionalita stačila pro integraci s .NET. Syntaxe XAML nebude dělat problémy nikomu, kdo ovládá .NET

Pro HTML based aplikace stačí zůstat u HTA, který lze ve spojení s ActiveX komponentama použít pro cokoliv - a od DHTML apliakcí se liší naprosto minimálně. Sotva ovšem mohou být tak strukturované, flexibilní a rozšiřitelný o další prvky, kolekce a rozhraní jako XAML - na to XUL nelepí:
<Button>
Hello World
<Button.Background>
<LinearGradientBrush >
<LinearGradientBrush.GradientStops>
<GradientStopCollection>
<GradientStop Color="Red" Offset="0" />
<GradientStop Color="Blue" Offset="0.25"/>
<GradientStop Color="Orange" Offset="0.75"/>
<GradientStop Color="Yellow" Offset="1"/>
</GradientStopCollection>
</LinearGradientBrush.GradientStops>
</LinearGradientBrush>
</Button.Background>
</Button>
Jednu z dalších věcí, kterou na XAML oceňuju je, že MS jako první pochopil, že syntaxe asociativních polí perlu používaná pro CSS nemá v XML co dělat. Styly/šablony tvořej důležitou součást dokumentů a neprosto nevidím důvod, proč by neměly bejt zpracovatelný XML parserem stejně, jako zbytek dokumentu.
Jeden z důsledků toho faktu, na kterej narazíte okamžitě je, že XAML dokumenty půjde transformovat bezebytku XSLT na XUL nebo XHTML - ale obráceně sotva....

V dobe kdy vznikala mozilla nebylo nic podobneho standardizovano.
<br><br>
Protoze te znam tluchubo, tak vim, ze o XUL nevis vubec nic, ostatne si pletes i moznosti a schopnosti CSS a XSLT, takze tve mineni co se na co lepi nebo nelepi je zcela bezvyznamne :-).

Jako kdybys nic neřekl...;-)

Ostatně, už jsi něco v XUL napsal? Myslím něco, co byse dalo nalinkovat na web a prohlídnout v Mozille ? Dokonce nalinkovat přímo sem ?

> Pro HTML based aplikace stačí zůstat u HTA, který lze ve spojení s ActiveX komponentama použít pro cokoliv .....
.....a nikdy to díky ActiveX nebude fungovat, protože ActiveX je propietální backdore do jistého nechvalně proslulého "OS" a nikdo, kdo má rozum, jej nenechává aktivní.

Schvalne si nekdy precti co umi Mozilla. Pres pluginy a XPCOM udela uplne vsechno co udela IE pres ActiveX, jen s jednim rozdilem - IE strasne rve pokud se uzivatel snazi instalovat neco bez podpisu. Mozilla nainstaluje uplne vsechno. A vyslednej efekt je jeden a ten samej - binarni kod bezici v kontextu browseru, bez jakychkoli omezeni. Samozrejme pokud budete tvrdit ze IE nainstaluje ActiveX kontrol bez ptani tak nema vyznam se o tom vubec bavit...

Jádro pudla bude asi tady "Pres pluginy a XPCOM udela uplne". Dostat do systému XPCOM objekt není taková trivialita, jako COM u Win. To, že IE instaluje (v řadě defaultních nastavení starších verzí, které ale řada lidí stále provozuje) je zkrátka fakt.

HTA aplikace neřvou, když se potřebují ActiveX nainstalovat bez podpisu.

Zkrátka netušíte, že něco jako aplikační režim pro MSIE existuje - to je pak ovšem těžká debata.

Jezisi, ohanet se HTA aplikaci je jako ohanet se ze spustitelny soubory muzou delat co chtej (i instalovat COM objekty aniz by o tom uzivatel vedel). Rozhodne nejsou zneuzitelny remotne, v principu sou stejne nebezpecny jako jakykoli jiny spustitelny aplikace. A ty sou nebezpecny (v ramci kontextu uzivatele) pod jakymkoli systemem. To ja pak muzu rict ze si embeduju Mozillu a vnutim ji bez ptani pluginy co budou nebezpecny - samozrejme ze to jde, stejne jako jdou zneuzit HTA aplikace. Ale pokud vim tady sme se bavili o browseru kterej prohlizi stranky pres HTTP/HTTPS.

Schvalne mi postni nekam na web aplikaci co v IE bez ptani nainstaluje nepodepsanej control. Evidentne vis jak na to...

...Globální avalonizace webu je utopií... Pokus redmondských inženýrů nahradit web Avalonem nejspíš vezme stejný konec...

No to jsou mi ale žvásty... :o(

Avalon přece zastřešuje funkcionalitu .NETu - sotva tedy půjde o platformu pro bezelstný spouštění full-featured aplikací z webu aby se vám mohly hrabat po disku a síti. Jde o platformu primárně pro trusted prostředí: klientské a off-line aplikace, intranety - běžící výhradně na Windows platformě. Až MS stvoří implementaci XAML pro ostatní platformy, pak můžete vyvádět kvůli "avalonizaci" webu. Nikdo vám přece tyhle věci na web necpe.

Jasne, stejne jako nikdo nikomu necpe nestandardni a neportabilni rozsireni IE a nebo treba MS formaty dokumentu se stejnou charakteristikou :-)).

Ovšemže necpe.

Tyhle věci by sis měl koupit.

<i>Až MS stvoří implementaci XAML pro ostatní platformy...</i> -- to bude bud nejaky jiny MS, nebo dusledek vetsi davky halucinogennich latek.

Přesně tak - potom ale nechápu, proč se tu blábolí o "avalonizaci webu" a "cpaní technologií"...;-)

Microsoft tyhle technologie vyvíjí pro sebe a pro svoji platformu. Jsou otevřený a standardizovaný u ECMA, nikomu se nebrání je implementovat taky (ala Ximian & mono) - ale tím celá tlačenka končí.

To je fajn, ale je otazka, jestli nebudou obaleny pevnou skorapkou patentu. To nas sice v Evrope (snad) nemusi moc trapit, ale v Americe to muze byt pomerne neprijemny problem a preci jen Amerika je pomerne slusny kus trhu.

Pekny clanek, ale postradal jsem v nem aspon malou zminku o Macromedia Flex http://www.macromedia.com/software/flex/ coz neni zcela zanedbatelna udalost ;-)

Vzhledem ke zkusenostem s www prohlizecem firmy MS, ktery je neprekonatelnym "rekordmanem" v bezpecnostnich dirach, pak doufam, ze Avalon aplikace "pujdou na squidovi zakazat" :-)

No to je snad urazka vsech normalnich lidi, kteri se snazi standardizovat veci tak, aby byly siroce pouzitelne. M$ sam vzdycky vyuzival uz existujicich technologii a stavel nad nimi neco, co bylo naprosto neprenositelne. Ted, kdyz se dostal do cela jakoby zapomel, ze standardizovane technologie a protokoly (TCP/IP, HTTP, ...) mu pomohly se do toho cela dostat jenom proto, ze byly standardizovane a tudiz bylo jednoznacne receno, jak to implementovat. Stavi svoje vlastni veci, ktere uz budou urceny jenom svetu M$. To je ale neslychana drzost. Pevne doufam, ze to vyfailuje nebo buh s nami.

Microsoft využíval existující technologie tak, aby byly přenostitelné na 95%+ desktopů. Kritizovat jeho přístup ke standardizaci tváří v tvář systému, který nemá dodnes standardizované ani rozhraní ke grafické schránce mi přijde jako neslýchaná drzost..;-)

Blbost. Nikoli na 95% desktopů, ale na jeho desktopy. To že se to -- shodou okolností -- rovná početně, neznamená, že je to totéž.

Microsoftí standardy nejsou o nic horší, než doporučení a standardy jiných subjektů. S ohledem na svou rozšířenost mají také statut de-facto standardů, čímž se W3C recomendations aj. rádoby standardy mohou chlubit těžko.

To, že MS standardy podporuje 95%+ desktopů znamená, že na 95%+ desktopech, ke kterým přijdete můžete počítat s nějakým standardním řešením.

Ve zbývajícím 1% Linuxu není standardní ani desktopové rozhraní - když si naprogramuji něco pro KDE toolkit (namátkou KRogue), můžu si být jist, že to nepoběží ani na všech desktopech z toho jednoho procenta, protože zbytek používá IceVM, Gnome apod. prostředí. To se pak těžko hovoří o standardech.

Pletes si window managery, desktopovy prostredi a gui toolkity. Udelej si v tom jasno a pak diskutuj. Bah!

Ono kdyby se alespon Microsoft netvaril, ze je clenem w3.org (http://www.w3.org/Consortium/Member/List), tak by jeho chovani mozna davalo smysl..ale kdyz se podili na vyvoji neceho, co se potom pokusi nahradit vlastnim rozsirenim...

Tohle je definicie formulare v Qt. Formular se zpracovav pri prekladu, ale nic Vam nebrani zpracovat jej pri behu a napojit signaly na sloty napr. v Javascriptu. Chapu to tak, ze Avalon by mel byt o necem podobnem?

<!DOCTYPE UI><UI version="3.2" stdsetdef="1">
<class>cap</class>
<widget class="QMainWindow">
<property name="name">
<cstring>cap</cstring>
</property>
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
<width>620</width>
<height>500</height>
</rect>
</property>
<property name="caption">
<string>Customer access protocol</string>
</property>
<widget class="QTextEdit">
<property name="name">
<cstring>imapEdit</cstring>
</property>
<property name="geometry">
<rect>
<x>10</x>
<y>10</y>
<width>600</width>
<height>450</height>
</rect>
</property>
<property name="paletteForegroundColor">
<color>
<red>255</red>
<green>255</green>
<blue>0</blue>
</color>
</property>
<property name="paletteBackgroundColor">
<color>
<red>0</red>
<green>0</green>
<blue>0</blue>
</color>
</property>
</widget>
</widget>
<toolbars>
</toolbars>
<includes>
<include location="local" impldecl="in implementation">cap.ui.h</include>
</includes>
<functions>
<function access="private" specifier="non virtual">init()</function>
</functions>
<pixmapinproject/>
<layoutdefaults spacing="6" margin="11"/>
</UI>

a s libglade to jde v Gtk...

Pockat pockat, znamena to, ze libglade pracuje se stejnym
<!DOCTYPE UI><UI version="3.2" stdsetdef="1"> ?

To se obávám, že ne ;-( Měl jsem napsat, že něco podobného lze s libglade.

Ano, s tím, že zpracování event událostí (signal slotů) bude realizované kompilovaným kódem běžícím v CLR.

Tohle se spíš podobá řešení v MS InfoPath. Ale jinak je to velmi podobné. Nevím ovšem, do jaké míry je to extenzibilní o deklarativní definice tříd a kolekcí stejně, jako XAML.

Dejte mi někdo pěstí, jestli plácám nesmysly, ale když open office pracuje s uzavřenými formáty MS office, mozzila s flashem atd... není to jen otázka dvou měsíců, než někdo sepíše plug-in pro mozzilu zobrazující Avaloňácký stránky? ;)

Ano, kdyby Mozilla místo JavaScriptu začala podporovat .Net/Mono. V něm se skrývá implementace funkcionality několik tisíc tříd, který za dva měsíce těžko odladíte. XAML je dynamicky jazyk, pomocí základních tříd si můžete definovat další - svým způsobem je založenej na deserializaci .NET tříd.

Ale wrapper pro <script language="C#"> není v případě MSIE tak obtížný napsat s využitím reflection, takže by to asi nějak šlo na podobný bázi i v Mozille.

... troufám si říct, že jsem si na toto téma v historicky již vzdálenější době zaexperimentoval docela dost. Ponechme stranou různé experimenty Microsoftu týkající se toho, jak zaujmaut i ty uživatele, kteří ještě docela nezapoměli číst a psát. Zajímalo by mě, proč se ve vývoji klient-side síťových aplikací opomělo několik směrů:

1) CGI běžící v browseru, ne na serveru: Javascriptové "document.write" je jen chabým náznakem toho, jak by mohly vypadat aplikace tvořící na základě různých podnětů opět interpretovaný vstup pro renderovací prostředí (nemusí jít jen o HTML...) Je to prostě jiná dimenze programování, která je objektovým programátorů cizí...

2) Sandbox pro běžný spustitelný binární kód: copak žádný operační systém nevěří svému setuid a chroot natolik, aby to bylo možné ?

3) A konečně to nejzajímavější: multiplatformní open source aplikace konstruované jako součást webu, které ejsou jakýmkoliv způsobem interpretované, ale na libovolné platformě se zkompilují do podoby spustitelného kódu. Něco takového je vlastně na základní textové úrovni apt-get install Debianu, ale proč něco takového nerozšířit na úroveň klikacího webového prostředí ? Jestliže se je dnes možné doklikat pouze k nějakým Javám, Flashům a Avalonům, které nemotorně plýtvají výkonem CPU na nějakou interpretaci, proč by prostě v budoucnu po kliknutí na odkaz nemohlo následovat (interně v počítačí, neviditelně pro uživatele) nějaké to ./configure a make install ?

To opravdu existují jen dvě formy distribuce programu - spustitelný kód a nějaký skript určený k interpretaci ? Proč neopustit paradigma browser=interpreter, a neudělat z webového browseru frontend pro plnohodnotný multiplatformní kompiler ?

ad 1) Je vhodné separovat parsovací, kompilační (jak layoutu, tak skriptů) a renderovací fázi tvorby HTML, jinak nároky na výpočetní výkon stoupají s kvadrátem objektů na stránce. Zkuste si 1000x přidat k tabulce metodou document.write nebo i přes DOM po jednom řádku a pochopíte, že je postupné vykreslování dokumentu pomalé. Tomu se Avalon runtime snaží vyhnout tím, že XAML dokument se načte do CLR jako jeden celek, naráz se předkompiluje do MSIL - a naráz se prezentuje i GUI. Proto může být rychlejší než JVM a Java based browsery (layout je statický, jako HTML), tak XUL intepretovaná Mozilla (vlastní aplikace je kompilovaná), dokonce rychlejší než MSIE (skriptovací jazyk je taktéž předkompilovaný do MSIL kódu).

ad 2) Sandbox existuje jak u .NETu (CAS), tak u Javy. Myslím ale, že by se dalo hodně udělat pro jeho zjednodušení a zpřehlednění - dnešní funkcionalita je složitá - a stejně tak je pro běžného uživatele složité nastavení i sandboxu (seznam toho, co se dá v snadboxu kódu na klientu povolit či zakázat čítá desítky položek: namátkou použití LDAP, služby DNS a dalších usermode služeb, syslogu, dialogových oken a popup dialogů, fronty zpráv, DB rozhraní jako je OLE DB a SQL NET knihoven, čítačů výkonů a profileru, tisku a/nebo výstupu na porty, použití registru a jeho jednotlivých sekcí, řadiče služeb, přístup k socketům, čtení zápis do proměnných prostředí, I/O do file systému a sandboxu, použití reflection, serializace a interop, security (Kerberos, ACL's, adresářových služeb, atd., přístup na jednotlivé porty (Web, FTP), volání unmanaged kódu, použití zásad zabezpečení systému a domény, vzdálené řízení, kvoty na GC paměť, disk nebo prioritu procesoru.).

3) To poslední se týká web start technologie Javy nebo .NETu - ovšem s native code kompilací. Myslím, že vývoj k tomu pozvolna konverguje už dnes v podobě JIT kompilace Javy apod. (aplikace se dokompiluje za chodu a postupně tak jak se moduly zavádějí do paměti) - ale pro plnou kompilaci by startovací doby aplikací byly v současné době neúnosné. Nezapomeňte, že funcionalita .NETu se opírá o nějakých 20 MB knihoven - i jen statické slinkování za takové situace hezkou chvíli trvá, nemluvě o kompilaci.

A pak - zavání to taky trochu neefektivitou - proč znovu a znovu kompilovat aplikaci jen proto, aby byla opět spuštěná ? Myslím, že zlatá střední cesta je ta, kterou realizují dnešní runtime platformy - není to ani zbytečně interpretované a dynamická jako JavaScrip či Ruby, ale ani tak statické, jako C apod. a navíc využívají on demand kompilace a CLR cache (opakovaně volaný kód se tahá z cache a nekompiluje se znovu).

Ale jinak máte pravdu - má smysl se nad základními koncepcemi zamyslet obecněji a revidovat je s ohledem na současný vývoj a dostupné kombinace a varianty.

Jen si prihodim do diskuze o standardech - .Net CLR a C# sou standardizovany ECMA, na rozdil treba od Javy, ktera je proprietarni (i kdyz multiplatformni, to ale nezamenovat) jazyk Sunu. Myslim ze z velkych firem to se standardama Microsoft mysli porad nejlip (viz IBM a jejich proprietarni vynuceny veci v XML 1.1 anebo Sun s jejich proprietarni nestandardizovanou Javou).