Vlákno názorů k článku Vývojáři navrhují přepsat Thunderbird pomocí web technologií od peterffffff - wow, emailovy klient v jave jsem delal jako...

wow, emailovy klient v jave jsem delal jako rocnikovy projekt na vysoke skole ... nechapu co je pry na tom neudrzatelne ? naprogramovano za 2 tejdny ...

mam pocit ze v dnesni dobe je uz vyvojarem kazdy blbec a tak to aj vypada ...

jinak tenhle thunderbird jsem skousel a jeste aj jine linuxove emailove klienty .. je to neco otrasniho ... fuj hnus ... odpad

To je reakce na co ve článku?

Mam pocit, ze dneska muze VS studovat kazdy blbec.

Má pravdu. Dokonce vidím důkaz - tebe

Můžeš někam hodit kód, ať se pobavíme?

Toto jsem asi taky nepochopil - místo aby se pochválilo koncepční oddělení, tak se považuje za chybu.
Nějak mi to celé nedochází, co tam čarují.

Taky mě to dostalo do kolen. Asi to má prostě znamenat, že nemají žádnou architekturu a lepí to jak plakáty na vrata...

V tomhle stavu to ale nechce přepsat do jinýho jazyka, v tomhle stavu to chce hloubkově refaktorizovat a důsledně testovat, aby se oddělilo jádro a to pak v poslední fázi vyměnit. Jinak můžou celý TB odpískat rovnou...

V XULu jsem delal, programoval jsem do nej XPCom componenty v C++. A popravde receno nic horsiho neexistuje. Puvodni Netscape bezel na spouste dnes jiz neexistujicich platformach. A z toho plyne rada omezeni. Vychazelo se z toho, ze fce jako malloc, read a write nejsou thread-safe. Takze aplikcace v XULu NESMI alokovat pamet mimo hlavni vlakno, dokonce ani nesmi cist ze socketu. Alokace pameti a komunikace se siti se smi provadet pouze pres nejakou mozilla knihovnu, ktere je obalkou nad Apache APR.

Komunikace se serverem musi probihat tak, ze nejaky bg thread ceka na socktetu a kdyz prijou data, tak posle zpravu do hlavniho UI threadu a teprve v kontextu tohoto threadu, muzete precist data ze socketu.
Pokud ma nekdo jiz tohovou knihovnu ktera komunikuje serverem na nejakem slozitejsim protokolu, tak ma smulu, musi si napsat novou knihovnu, ktera bude odpovidat dogmatum XUL.

XUL navic nema "extensible marshaller", tzn, nemuzete vytvorit nejaky novy typ zpravy, kterou byste posilal z bg threadu, a zpracovaval v hlavnim event-loopu.

Zatimco u ostatnich aplikaci je normalni, ze pro komunikaci se serverem pouzivate nejaky ovladac anebo knihovnu, a o implementaci protokolu se nestarate, v XULu si vse musite napsat znovu. Musite ten ovladac rozdelit na dve casti, jednu pro gb thread, druhou pro UI thread.

PS: docela me zarazi, ze Rust navrhli ti sami lide, kteri vytvorili tohleto. Napr. komunikace mezi C++ komponentou a JS enginem SpiderMonkey, probiha pres datovy typ "void**", ktery si musite vselijak divoce pretypovavat podle potreby.

> Komunikace se serverem musi probihat tak, ze nejaky bg thread ceka na socktetu a kdyz prijou data, tak posle zpravu do hlavniho UI threadu a teprve v kontextu tohoto threadu, muzete precist data ze socketu.

To je vcelku bezny design, ktery nesouvisi s XUL. Knihovna (v C/C++) nema co predpokladat, jak je resena aplikacni I/O loop, a tedy nemuze delat blokujici akce. Rozumna knihovna ma funkce, ktere to umoznuji osetrit (napr. aplikace zavola knihovni funkci, kdyz na socketu je mozne provadet I/O, a knihovna si I/O zpracuje, knihovna zavola hook, pokud je treba pridat dalsi socket do I/O loop).

Obavam se, ze jsem podobnou knihovnu dosud nevidel. Alespon ne pro mysql, postgresql, ldap, imap anebo jabber. Na druhou stranu uz je to davno co jsem s tim bojoval. Zatim jsem videl jen situace kde se tohle obchazi tim, se pro IO socket vyhradi vlastni thread.

Tak 14 dnů asi stačit nebude, ale co budou dělat ty 4 roky, mi taky není jasné.

No co by?
1. rok - budou diskutovat, jak bude vypdat architektura
2. rok - budou se hádat, jaký jazyk je nejvíc cool
3. rok - budou se usmiřovat a psát kompilátor TPL (Thunderbird Programming Language), na kterým se shodnou jako na kompromisu.
4. rok - půlka kóduje, druhá půlka řeší, jak oznámit uživatelům, že se to nestihne.