Vlákno názorů k článku 600MB přílohy na Centrum.cz po čtvrt roce od Dan Ohnesorg - Jeste lepsi by bylo prepsat rsync do javascriptu...

Jeste lepsi by bylo prepsat rsync do javascriptu a tunelovat to metodou CONNECT.

HULANE - KDE JE TEN SLIBENY CLANEK??? Me nezajima antivirus a antispyware. Specialne antispyware pro muj OS nikdo nechce udelat.

A co použít FTP protokol?
Je efektivní, umožňuje oboustrennou komunikaci, umožňuje navazování přerušených přenosů, ...

Možná chce trochu trik implementovat přístup přenositelně a bezpečně, ale snad by to za tu námahu stálo.

Jo, tak timto "argumentem" jste mi vazne vyrazil trumfy z ruky ;-)

... a vůbec nejsnazčí je kabelovej přenos :-)

Povazuji rozkouskovani pomoci HTTP/POST via JavaScript za neporovnatelne snazsi nez jakykoli jiny navrhovany zpusob...

V prubehu threadu jste navrhoval posilani souboru po mensich castech, coz jsem pochopil tak, ze by se prohlizec mel postarat o rozkouskovani a poslani jednotlivych casti (=javascript nebo nejaky jiny aktivni prvek na strane klienta). Na coz jsem odpovedel ze v tom pripade se ten kouskovac muze rovnou postarat i o odeslani nejakym chytrejsim protokolem. Takze ano, at to udela klient pomoci nejakeho aktivniho prvku. Mailovou aplikaci Centra sice neznam, ale nepocitam ze by fungovala na zaklade cisteho HTML a tlacitka "Send".

Už pěknejch pár let umí hodně prohlížečů Javu a někerý ActiveX :-)

Jenze jste zapomnel na takovou drobnost - kolik WWW prohlizecu vubec HTTP/PUT umi odeslat/zpracovat (nebo to si chcete vsechno zpracovavat ve vlastni rezii i na strane klienta)? (Proc potom pouzivat WWW prohlizec, to uz muzeme mit specialni aplikace nebo lepe aplikaci ve std. sandboxu - .NET, JVM apod.) Myslim si, ze z kontextu je dostatecne zrejme, ze se bavime o environmentu WWW prohlizece - tady je technologicka a interoperabilni zakladna opravdu bohata a ruznoroda, nicmene spolecny (= bezny) prunik vlastnosti a technologii k dispozici je rovnez velky, lec bohuzel alespon dle mych vedomosti do tohoto pruniku HTTP/PUT nezapada...

1) Uz jsem si rikal ze vas ta hadava nalada presla a ono ne. Ono to bylo vikendem...

2) Kdyz si o necem myslim ze to neni dobre tak to automaticky nemusi znamenat ze to dokazu udelat lip. Spatny film poznam a i kdyz dobry natocit neumim, nebrani mi to rict, ze ten film podle me stoji za starou backoru.

3) Pozadavky ktere by podle meho nazoru mel umet pouzity protokol jsem zde jiz nekolikrat napsal - binarni prenos (to umi i POST, ja vim), obnoveni prenosu po jeho rozpadu, pokracovani i z jine IP adresy, paralelni prenos vice kusu souboru najednou a v idealnim pripade i update, tzn. pokud zdrojovy soubor nepatrne zmenim aby se nemusel prenaset cely znovu. Precejen se bavime o prenosu relativne velkych souboru po relativne nespolehlivych linkach. To uz chce trochu robustnosti.

4) Temto pozadavkum se v protokolu HTTP nejvic priblizuje metoda PUT. Sice neumi vsechno co jsem zminil, ale je urcite praktictejsi nez POST, ktery bez dodatecneho znasilnovani ze zminenych vlastnosti nesplnuje skoro zadnou.

5) Tahle debata uz me nebavi. Vy porad dokola opakujete POST POST POST a nenechate si to vymluvit i kdyz vam zde snasim argumenty proti. Dostavate snad tantiemy z kazdeho pouziteho POSTu?

6) Tahle debata navic ani nema smysl - jednak nevim jak presne Centrum ty soubory prenasi a kvuli nam stejne nebudou svou aplikaci predelavat. Kdyz jsou jejich uzivatele spokojeni s tim co maji, tak jim to budiz prano.

Prozradite mi jiny std. protokol, ktery je na takovy prenos vhodnejsi (on to totiz neni push-in na klienta, ale push-out na server a tam techmoznosti nemame zdaleka tolik...). Z meho pohledu je totiz uplne ukradene, jakym transportnim protokolem to budeme tahat na server - nejlepe takovym, ktery ma malou rezii, slusnou uroven abstrakce a zabezpeceni a je standardne podporovan... - takovy protokol neni SMTP (diky nesrovnatelne vetsimu overheadu), ale takovy HTTP/POST urcite ano...

Kdyz rikate, ze HTTP POST je na takove veci mizerny a nevhodny, urcite mate lepsi reseni - skoda jen, ze jste se o nem zatim nezminil...

To je ovšem úžasně "pratické" řešení. :D

Svoje veci mam taky na disku a muzu na ne odkud chci, oni totiz existujou veci jako treba SSH :-p A nepotrebuju na to ani nejakou kavarnu, staci mobil s javou ;-)

Jasně, uživatele nezajímá, že jeho osobák těch pět tun štěrku neuveze, on si je prostě chce (tady se mi vybavuje tříleté dítě, jak mlátí pěstičkami a vykřikuje "Já chci! Já chci!" - a nebo Marfuša) odvézt… Copak on může za to, že lidi z oboru nepostavili osobák na takové náklady a pořád prudí s tím, že má použít náklaďák?

Vase filozfie je stejna jako vetsiny IT lidi. Uzivateli je jedno, ze to k tomu neni stavene - oni si chteji navzajem posilat velke soubory. Na IT lidech je, umoznit jim to. Ja osobne (a to jsem IT) nevidim JEDINY DUVOD, proc nepouzivat k prenosu velkych souboru mail. Ano, protokoly na to nejsou stavene, ale to proboha neni problem uzivatelu!!! Copak oni muzou za to, ze IT lidi doposud nevymysleli protokol, pro ktery to problem neni????

Tak zkus Gmail, tam je právě teď 2464 MB a pořád to roste. :D

Ja mam 1 GB na Centru a po mesici mam obsazeno 7%, zadne multimedialni ani binarni prilohy, vetsinou maily s TXT prilohou, sem tam nejaky DOC. Pouze prichozi posta. Spamy mazu. Historii mit musim. Do doby nez existovaly sluzby s takovouto kapacitou jsem mel kompletni komunikaci pouze v INBOXU na HDD. Nyni je mam odkudkoli k dispozici, kdyz se potrebuju podivat na mail z 5.7.2005 z kancelare, tak se podivam, stejne jako z kavarny v Dubrovniku. Za rok/dva budu muset mazat = 1 GB je malo.

1 - 5 MB? A nebude lepší jenom textové e-maily bez diakritiky a to ještě velmi krátké, aby se nám ten Internet nepřetížil?

Je pravda, že 600 MB v praxi je blbost, v praxi to téměř nikdo nevyužije stejně jako 2 GB schránku Googlu. Tomu se říká marketing.

Na druhou ustranu se třeba 10 MB příloha hodí (když vím, že má druhá strana dostačující připojení), obzvláště když něco posílám BFU. Je to rychlejší než ho nebo ji zasvěcovat do tajů FTP. V úvahu potom přichází ještě třeba yousendit.com.

Covece vy mi svou fanaticnosti pripadate jako kdybyste tu aplikaci pro Centrum psal vy!

1) "A co z toho plyne? [...] ze POST ma sve hranice pouzitelnosti?"

Jste docela sikovnej - uz po trech prispevcich na stejne tema jste me pochopil. Ano, POST je dobry ale ma sve hranice.

2) "Mimochodem, co si myslite, ze se stane, kdyz klient spatne pozada server o chunk pri GET? Vite ze vubec nic, [...]"

No a? Tvrdil jsem snad opak? A jak to souvisi s tematem? Vy dneska mate hadavou a nejaky tema si proste najit musite, zejo? Ale to nic, to prejde, uvidite :-)

3) "Opravdu nemohu za to, ze HTTP POST ma sve hranice [...]"

Nejsem sice psychiatr, ale tipnu si ... paranoia? Ja vas prece neobvinoval ze muzete za zpusob jakym funguje POST. Dokonce jsem neobvinoval vubec nikoho - ten protokol tak proste je navrzen. Jestli hodlate soubor u klienta automaticky kouskovat a posilat po castech tak na to budete muset mit klientsky javascript/javu/activex/... a to pak uz rovnou muzete vyuzit nektery z protokolu ktere jsou pro dany pripad vhodnejsi. Ano ano ano, nerozcilujte se, muzete pouzit i POST, jo, fakt, nikdo vas za to k soudu nepozene. Ale optimalni reseni to jaksi neni - kdyz uz u klienta bude nejaka aktivni komponenta na rozkouskovani, tak zrovna muze zaridit i chytrejsi prenos. Jinak je to podobne znasilnovani protokolu jako poposilani mailu pres ICMP. Jde to, ale dre to.

Mejte se pekne ja jdu spat. Muzeme to dohadat rano (resp. u vas vecer).

A co z toho plyne? Ze HTTP je dobry protokol, ale metoda HTTP POST uz ne? Nebo jen to, ze POST ma sve hranice pouzitelnosti? Mimochodem, co si myslite, ze se stane, kdyz klient spatne pozada server (ktery takovouto vec nemusi podporovat (kam je klient vul, ze o to zada)) o chunk pri GET? Vite ze vubec nic, server proste posle cely URI objekt a klient to kupodivu rozkoduje protoze se v hlavicce nikde nedozvi odkud pokud to server poslal (= 0-MAX).

Opravdu nemohu za to, ze HTTP POST ma sve hranice, mimochodem, to je takovy problem na strane klienta pouzit ten post, ale rozkouskovat to do nekolika POST requestu? Na serveru sesbirat, seskladat (stejne se to uklada nekam do tempu a pak necha zpracovat vyssi vrstvu/y)? Takze si stojim za svym - klidne necht se pouzije HTTP POST, ale rozumnym zpusobem... u SMTP lze samozrejme udelat to same, ale to seskladani je veci by hand... - tady to lze udelat strojove a proto to vidim jako znacny posun.

Dneska jste se spatne vyspal, ze jo?

Ja nemluvil o HTTP obecne, ale o metode POST protokolu HTTP. Zkuste si moje prispevky jeste jednou precist. HTTP je dost genericky na to aby se pomoci neho dalo prenaset prakticky cokoliv. Jeho metoda POST takova neni - ma sva omezeni a z toho plynouci nevyhody.

WebDAV nepouziva POST ale PUT - to je neco zcela odlisneho. To jste vazne nevedel?! Teeeeda, takovy zaklady! Ale to nic, treba na to jednou narazite...

Mozna byste mi mel vysvetlit, proc by neco takoveho mel HTTP (!!!) protokol umet... HTTP protokol se pouziva jako middleware, pomoci ktere vyssi vrstvy delaji dalsi (sofistikovanejsi) operace (= je to URI + sitovy transport - i tu autentizaci si musite udelat ve vyssi vrstve, protokol sam to nijak nezpracovava)... zrejme jste nikdy neslysel o WebDAV/DeltaV protokolu (kupodivu prenasenem pomoci HTTP), ale to nic, treba na to jednou narazite...

Za prasarny v implementaci nemohou ani tvurci protokolu ani panbicek, pouze prasata implementatori... to je jako byste se rozciloval, ze nekdo to posle via UUENCODE stream v ICMP packetech....

Copak IPv6, ale ty aplikace kdyby to umely (a samozrejme widle, to co je ve winXP ...). Jen je problem v tom, ze na IPv6 zdroj narazim opravdu malo kdy, takze jako BFu si muzu rict "naco IPv6, kdyz se pres to stejne nikam nedostanu".

Tak treba na prenos souboru smerem ke klientovi - umi resume (via partial content), je celkem fuk jak velky soubor stahuju a klidne ho muzu stahnout na nekolikrat treba i kdyz se mi v mezicase zmeni adresa. Ale neznam klienta ktery by se podobne dokazal chovat i pri uploadu (a kdo vi jestli to protokol vubec umoznuje).

Takze posilat pul gigo v HTTP-POSTu je zbesilost zbesila nehezka fuj.

A keď má niekto prístup na 100 Mb linku a nemá možnosť mať spustený FTP server?

A na co je tedy HTTP stavene?!

a zrovna i posilani fotek je jiz trosku out, je tady rada sluzeb jako sonyimagestation.com nebo tusim hello.com, ktere posilaji jen link na upload vasich fotek a po mailech necestuje nic...

takze i nejake zmensovani atd mi prijde dost dost pracne a zbytecne slozite..

Hm, ta je fakt c00l ;-)

dan@dan:~> ping6 2001:5c0:83d7:0:c001::1
PING 2001:5c0:83d7:0:c001::1(2001:5c0:83d7:0:c001::1) 56 data bytes
From 2001:5c0:0:2::18 icmp_seq=1 Time exceeded: Hop limit

akorat by to chtelo jeste postelovat to routovani.

Souhlasim se vsim. Jeste maly dodatek: kdyby nebyli ISP liny zavadet IPv6, byly by NATy zbytecne ... a navic by lidi mohli mit cool (resp c001) IP adresy (napr: 2001:5c0:83d7:0:c001::1) :-).

Virtualni vzdaleny disk by byl prima, ale to by nikdy nedokazali utahnout.

Z jejich pohledu potrebuji reseni:

- ktere umozni zobrazovat reklamu, ktera jej zivi

- umozni uzivateli vsude rikat, ze ma ten cool mail s 600M prilohami, ale ve skutecnosti bude tak slozity na obsluhu, ze toho vyuzije jen male mnozstvi uzivatelu

- ktere ztizi uzivateli moznost zneuzit jej jako dalsi disk pro ukladani toho, co se mu doma nevejde, tohle dobre osetrovaly ty vernostni body, co bude ted, kdyz si kazdy zalozi sto schranek a bude si nejnovejsi filmy posilat mailem sam sobe, aby je mel zalohovane a davat hesla ke schrance kamaradum, aby se k nim take dostali....


Proste vzdaleny disk by asi nebyl to prave. Nejaky klinetik by byl lepsi, ale jak by zobrazoval reklamu? Vyskakovacim oknem? To by lidi pekne prudilo.

Podle me se na posilani takovych veci mimoradne hodi IM klienti. Jen je potreba vymytit NATy, aby IM klienti mohli komunikovat bez prostredniku.

No vidíte, prakticky jste rozvedl mou myšlenku. Ale Centru nepatří chvála, protože jednoduše udělali dobrou věc špatně.

Vždyť i v článku je:

---------------------------------------------
Jediné, co Centrum shledává negativním, je kvalita připojení části uživatelů. Nahrávání přílohy trvá dlouho a proces může být přerušen. "Uživatelé to někdy dávají za vinu nám", poznamenává Oldřich Bajer.
---------------------------------------------

Což je ovšem jednoznačně chyba centra. Oni uživatelům řekli, že mohou posílat 600MB přílohy mailem. Tečka. Nikdo jim neřekl, že se odešlou data jako HTTP POST v b64 kódování (tj. nebude se posílat 600MB ale 900MB) a že je velká pravděpodobnost, že spojení samo lehne, ať už kvůli kratinkému výpadku, chybovosti prohlížeče, nějakého timeoutu kdoví kde. Ať centrum zveřejní, kolik bylo pokusů o upload souboru většího než třeba 50MB a kolik z nich dobře dopadlo. Dle mých zkušeností jich asi moc být nemohlo. 50 % ?, 30 % ?

Když už chtěli udělat dobrou službu, určitě šlo integrovat něco do lišty, activex, java appletu, aby uživatel nic nepoznal a přenos zaručeně probéhl (8b, s navazováním). IMHO by bylo nejlepší řešení integrovat do emailu virtuální vzdálený disk (jako to mají jinde) a naučit uživatele nahrát soubor na disk a do mailu dát jen odkaz.

Nic Vam nebrani ucastnit se praci v IETF na novem protokolu pro prenos posty :-)

Spíš je to realita a vůbec na přehnaná. Nedávno jsem potřeboval poslat asi 15 fotek o velikosti cca 10MB. Jelikož dotyčný je potřeboval vidět pouze orientačně, tak jsem jim zmenšil rozlišení a jedna fotka měla něco málo přes 100kB. Počítačová gramotnost příjemce je tak žalostná, že než bych pak poslouchal ty blbé kecy, proč ho to nutím stahovat někde z webu, že pak neví, kde se mu to uložilo, bla bla bla ..., tak jsem to poslal ve čtyřech mailech. Každý měl mít cca 400kB, ale do jednoho se mi připletla jedna nezmenšená fotka, mail měl rázem něco přes 1MB a jako jediný nedošel. Nevím jestli byl na vině SMTP server Eurotelu, freemail na Seznamu, nebo cokoliv jiného, ale realita je taková a není to ojedinělý případ.

IMHO největší problém je naučit BFU rozumnému používání nástroje s jim přijatelným rozhraním - technologie se mění podstatně jednodušeji, protože je záležitostí specialistů.

IMHO e-mail je principem služba určená k posílání dopisů a je na "pošťácích" aby začali vozit i balíky. Za větší ostudu než neznalozt BFU považuji nepokračování ve vývoji komunikačního protokolu specialisty tím směrem, aby služba byla efektivní.

V současnosti prostě narůstá kapacita připojení i velikost uchovávaných souborů a existuje poptávka po jejich přepravě. Argumenty o šetření sdílených kapacit považuji za správné pokud jde o sdílení cizích/věnovaných zdrojů (původní nekomerční intarnet, komunitní WiFi, ...). V současnosti však už velká část (?většina?) uživatelů za poskytnutí síťových zdrojů platí a z tohoto titulu mají IMHO právo je využívat způsobem, který potřebují. Pokud by toto chování zatěžovalo společné zdroje nad přijatelnou míru, tak budou muset být tyto zdroje posíleny a to se bude platit z ceny připojení nebo dle míry využití "vzácného zdroje".

ad a) To že pro přenos pošty je používáno současné SMTP považuji za chybu architektury a podle mne už dávno mělo být zavedeno rozšíření umožňující :
1 - binární přenosy (bez překódovávání do 7mi bitů)
2 - převzetí příloh přímo ze zasílajícího serveru (např. FTP protokolem ale tak, aby to BFU nemuselo zajímat) nebo s odloženým doručením po odsouhlasení příjemcem (aby to neumožňovalo přetěžování serverů nevyžádanými přílohami)
3- zotavení přenosu příloh po chybě přenosu (dle implementace 2)

ad b) "Nikdo" není pravda, někteří uživatelé tuto možnost mají a jejich počet prudce vzrůstá. Otázka použitých protokolů je pouze záležitostí implementace ale ne principu služby. Dovedu si například velmi dobře představit, že tlačítko přenosu přílohy bude v sobě obsahovat aktivaci FTP spojení do domovského adresáře uživatele (příjemce ? odesilatele) s OTP ověřením + mazáním po úplném vyzvednutí všemi příjemci a přitom to pro BFU pořád bude jen stejné tlačítko bez nutnosti zvládat další neznámý nástroj (např. příkazy řízeného ftp klienta od MS).

Internet je pro "nemístné" aplikační experimenty ideální místo a Centrum se pokusilo uspokojit existující poptávku - za to jim patří čest a chvála pro průkopníky.
Věřím, že se časem podaří najít technologické vylepšení. Pokud kdokoli ví o možných vylepšeních, navrhněte je Centrumu, Seznamu, Gmailu nebo jako RFC ...

Nikdo nerika ze se internetem nemaji prenaset velke soubory. Ale ani SMTP ani HTTP POST na takovou cinnost urcite nejsou stavene. Nedokazi paralelni prenos, prenos po castech, obnoveni spadleho spojeni, navic binarni data prevadi na sedmibitova (koduji do base64?), takze znatelne narusta objem.

Kdyz ma Centrum potrebu umoznit uzivatelum uschovu dat na svych discich, tak at k tomu vymysli nejaky chytrejsi protokol a napise pro BFU klikaciho klienta.

Ale propagovat to jako "nase posta umi 600MB prilohy" mi taky nepripada zrovna vhodne...

Myslíte že laik rozlišuje nějaké vaše SMTP a jakési GUI? Kdepak. Jednou se to naučil posílat (šlo to), tak proč by to nezkusil až bude pracovat v Outlooku... 200MB fotek přímo z foťáku, drag & drop a jedem. Mail jako mail, no ne? Takže si svoje řeči o nesouvisející kritice nechte od cesty.

A kdo řekl, že nemá smysl vytvářet služby pro menšinu? To jste si vymyslel, vy jste ten názor vůbec nečetl. Já říkám - dobrý pokus Centrum, ale tudy cesta nevede. Je třeby vymyslet něco lepšího.

Ad a: Nechapu, proc vsichni zamenuji "odeslat 600MB prilohu protokolem SMTP" a "odeslat 600MB prilohu prostrednictvim GUI mailoveho klienta". Pokud vidim dobre, centrum.cz implementuje tu druhou vec. Vase kritika prvni veci je tedy opravnena, lec nesouvisejici.

Ad b: <sarkasmus> Jasne, nema smysl vytvaret sluzby, ktere vyuzije jen mensina lidi. Navrhuji s okamzitou platnosti zavrit vsechny tenisove kurty, protoze nas normalni lidi s nadvahou a spatnymi plotenkami jejich existence jen urazi. </sarkasmus>

Tento názor patří spíš do starých pověstí českých,to bychom taky dodnes mohli místo dvd posluchat doma krystalku:)

si trochu protiřečíte, mluvíte o vychování uživatelů a pak radíte lištičku do MSIE, vychovaný uživatel MSIE nepoužívá, MSIE není na browsení webem dělaný

600 MB přílohy jsou nesmysl.

a) léta uživatelům vysvětluji, že posílat mailem přílohy nad 1-5MB je nesmysl, email na takovýto druh komunikace není udělaný. Velikost při přenosu uměle naroste a pak přesun blokuje (zbytečně zatěžuje) poštovní servery. Cílem by mělo být naučit uživatele efektivně používat stávající nástroje a ne je navyknout na odsouzeníhodné zvyky.

b) 600MB nikdo neuploadne. Český trh je specifický tím, že i když má někdo tzv. "broadband", tak má upload neadekvátně nízký. Tlačit tímto kanálem desítky MB je záležitost na dlouho. Nemluvě o vyrovnání se s různými problémy při odesílání - drobné výpadky spojení, timouty prohlížeče. Http POST není na velké přílohy udělaný a nepřežije ani drobounký výpadek, kterého by si uživatel ani nevšiml. Třeba IE se někedy zasekne naprosto bezdůvodně. Při problému bude frustrovaný uživatel zkoušet odeslat přílohu znovu a znovu a tím zbytečně zatěžovat infrastrukturu. Ať centrum udělá statistiku, kolik % přenosů se nějak přeruší a kolik dobře dopadne.

Centrum by nemělo zkoušet nemístné experimenty a místo toho by se měli snažit vyřešit problém odesílání velkých balíků dat mezi uživateli nějak jinak. Http ale určitě není řešení... pořád se chlubí že jsou vizionáři, tak ať se ukážou. Ať třeba udělají lištičku do IE s bittorrent klientem (přílohy mnoha různých uživatelů bývají často stejné) nebo co já vím :)