....
Jediné, co Centrum shledává negativním, je kvalita připojení naprosté většiny 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.
Taky se Vam zda, ze vyjadreni "prace s velkymi soubory je internetovou realitou" a "negativnim ... je kvalita pripojeni naproste vetsiny uzivatelu" si vzajemne odporuji?
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....
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.
Cely problem neni o tom, zda ma babicka nebo vnucka prstup k nejakym fotografiim. Cely problem je v tom, ze provozovatel systemuproste vybral spatnou sluzbu a spatne protokoly k implementaci. Duvody si mohu pouze domyslet - nedobra uroven vyvojaru, prosta neznalost problemu, podfinancovani projektu nebo neexistence alternativniho byznysplanu.
Urcite se da navrhnout takova sluzba, ktera splni pozadavaky jako uzivatelska pritulnost, financovatelnost reklamou a pouzitelnost pro vetsinu uzivatelu.
Nebudu urazet Tvoji odbornou erudovanost tim, ze bych Ti vykladal, jakymi jinymi zpusoby lze realizovat prenos dat. Verim, ze Tvuj odstavec, kde pises o "jedinem schudnem reseni" jsi napsal pred tim, nez jsi se nad tim problemem zamyslel.
Zdravi Te
Michal
AFAIK je upload zcela nezabezpeceny.
Co se tyce onech mraku warezu, predpokladam, ze okopirovat jednu z technik teroristu (kterou pochopitelne vymyslel nekdo uz pred davnymi veky a zove se mrtva schranka), kdy vicero lidi zna heslo k jedne schrance a nechavaji si "rozepsane" e-maily (v nasem pripade warez), nebude zadny problem ani pro mensiho giganta, nez jsi Ty.
Mimochodem ta myslenka resena na strankach nejakeho fora v CZF je zcela absurdni :-) Kdyz spadne SMTP prenos v polovine, zacne se posilat cely e-mail odznova. Tudiz jeden spatne nakonfigurovany mailserver (s povolenymi velkymi prilohami) ve spolupraci s trubkou userem a jednim padajicim spojem muzou vyvolat fakticky pekny denial of service (utok na funkcnost sluzby).
Zdravi Te
Michal
Reseni zvolene Centrumem NENI dobre. A to predevsim z duvodu, ze neni univerzalne pouzitelne a dokonce je pouzitelne jen pro hodne malou skupinu uzivatelu (s upload kapacitou v radu megabitu za sekundu).
Zdravi Te
Michal
Skutecne povazuju za vhodne, aby ses nad tim problemem zamyslel. Pokud ses nad nim zamyslel a na nic neprisel, tak se holt neda nic delat. Bud mas nejakou okamzitou tvurci krizi nebo Tva odborna erudice je pouze "urban myth".
Metoda HTTP POST neni vhodna pro upload zadneho vetsiho souboru. A to jak v pripade 56 Kb/s, tak v pripade 10 Mb/s na strane uzivatele.
Netusim, co nezyvas "me pojeti". Budiz Ti vsak omluvou, ze pravdepodobne netusis, ze mym dennim chlebem je prenos opravdu velkych objemu dat pres Internet. At jiz asynchronne (velke soubory) nebo synchronne (on-line editovani videa, proudovani videa). Ve svete existuji ruzne sluzby a protokoly, ktere resi problem velkeho prenosu dat. Verim, ze recenzi RFC se dopracujes k takovym protokolum. Jejich implementace je pak otazkou vyvojaru.
Mimochodem, implementace dotycneho reseni neni otazkou toho, zda existuji nebo neexistuji nejake protokoly nebo sluzby. Je to otazka toho, zda nekdo takovou sluzbu dokaze financovat. Ale vykladat Ti takove triviality jest otazkou noseni drivi do lesa.
Zdravi Te
Michal
Obavam se, ze jsi necetl diskusi pozorne, pripadne jsem to podal nejasne. Nevim, jak jsi dosel k nazoru, ze doporucuji nejakou peer-to-peer sluzbu - v mych diskusnich prispevcich se to neobjevilo. To je pochopitelne nesmysl.
Dale Ti doporucuji, abys zkusil popremyslet o tom, jaky je rozdil mezi protokolem, aplikaci a sluzbou. Predpokladam, ze sis to jen ve sve genialnosti neuvedomil a trosku jsi to pomotal. Dokonce i do weboveho prohlizece lze implementovat ruzne protokoly. A mam za to, ze princim single sign-on uz byl vysvetlen - vcetne toho, ze nemusi byt pouzivan pouze pro web (ci dokonce pouze pro jednu sluzbu).
Reseni Centra je spatne, protoze protokol HTTP post trpi celou radou problemu at jiz pro pomale nebo rychle pripojky.
Mimochodem pokud Tvuj kus kodu mel slouzit k memu zacykleni, zcela jiste by splnil svuj ucel. Pokud mel slouzit k precteni poslednich deseti komentaru, pravdepodobne tam mas nejake mouchy :-)
Zdravi Te
Michal
Jiste se mnou budes souhlasit, ze vyvoj gigabajtoveho e-mailu stal Centrum nejake ty penize. Dokonce si myslim, ze si i zaprogramovali (pravdepodobne ve Tvem oblibenem C++).
Pokud vezmu do uvahy, ze by ta sluzba mela bezet pouze v MSIE a OE (coz je ovsem hloupost) pak je to velmi jednoduche. MSIE se da pomerne slusne rozsirovat. A to tak, ze uzivatel nema s instalaci problemy.
Neni zadny duvod, proc se v pripade, ze jde o samotnou funkcionalitu sluzby, dloubat v business-like mysleni. Viz prvni verze clanku ("nejvic problemu .... maji uzivatele s uploadem").
Osobne se domnivam, ze 600 MB priloha je jen takovy marketingovy canc. Centrum ho zavedlo tak, aby to moc uzivatelu nemohlo vyuzivat a bude ho pouzivat nejmene do doby, nez nejaky student dostane na predmetu Operacni system Unix zapoctovy ukol: Napiste userspace ovladac k centrum-fs nebo dokud si pres to nezacnou studenti vymenovat velke fajly.
Zdravi Te
Michal
Zkousel jste jiz uploadovat pres HTTP post dve hodiny?
Mimochodem, neznam implementacni detaily e-mailu centrum.cz, nicmene standardni Apache uklada vsechno, co mu prijde nejdrive do RAM a az nasledne z toho dela soubor.
Kontrolni otazka: kolik maji servery e-mail centrum.cz RAM a kolik jich je?
Skoro to cloveka laka vyrobit si par uctu na centrum.cz a vyzkouset to :-)
Take Vas asi neprekvapi, ze Vas prohlizec nahraje cely soubor do RAM pocitace a i kdyz dnes ma spousta pocitacu hodne velkou RAM, prece jen 600 MB je slusna davka.
No a nakonec, jiste vite, ze signalizace prohlizecu pro stav uploadu je vice nez mizerna.
Zkousel jste skutecne nekdy poslat tech 600 MB pres HTTP POST?
Zdravi
Michal Krsek
To je ale hodně podstatný rozdíl. Mimochodem, už to, že jste v první větě mimoděk použil slovo samozřejmě, IMHO o něčem svědčí…
Nezdá se mi, že by tu někdo nadával na protokol HTTP, dokonce ani na metodu POST ne. Pouze tu několik lidí (marně) upozorňuje, že oboje je nástrojem, který byl navržen k určitému účelu a který k tomu slouží docela dobře, ale tím účelem celkem očividně nebyl upload 600 MB souborů. Je také celkem jasné, jak by měl vypadat protokol, který by se k takovému účelu hodil mnohem lépe. Stejně jako vy a další "idioti" (pravda, ještě jste tak nebyl označen, ale to je jen otázka času :-) ) si (na rozdíl od Radka Hulána) nemyslím, že skutečnost, že takový protokol není implementován do MSIE nebo MSOE, je důvodem, abychom mermomocí zavrhovali technicky vhodnější řešení a snažili se za každou cenu používat HTTP (a metodu POST) k účelu, ke kterému se jednoznačně nehodí. Koncepce TCP/IP byla navržena s určitou myšlenkou a rozhodně si nemyslím, že by touto myšlenkou bylo zatracení každého, kdo by si dovolil použití jiný protokol aplikační vrstvy než jeden z těch dvou (resp. čtyř, bereme-li v úvahu ještě POP3 a IMAP) oficiálně schválených všemocným Übersoftem jako Jedině Správné.
BTW ta zminena okolnost, ze se to rve do pameti je sice hezka vec, ale uz treba i takove php 4.X experimentalne experimentuje se streamy... a vzhledem k tomu, ze HTTP/POST (tak nenavideny zde na vetsi soubory... se divim, ze jeste komunikujete via SMTP kdyz je tak nevhodny na soubory vetsi jak 512kB - to jsem se ve skole (VS) taky ucil!) je ve sve podstate streamovy v tom nevidim problem, jo ze implementace teto casti v jistych produktech je rekneme kulisacky osrana, to je vec druha...
A co se tyce toho POSTu, staci to nervat cele do prostoru procesu, ale ukladat na disk a pak zretezit/navazat deskriptory souboru - STDIN pro zpracovavajici aplikaci a FD souboru kam se to ulozilo po ceste ze site.
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.
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...