Vlákno názorů k článku
Jak rychle poslat velký objem dat? Přes úschovnu

No pokud bych chtěl někomu poslat velký objem dat který už se nehodí do emailu tak ho hodím na FTP. Posílat soubor o velikosti stovek megabajtů přes webové rozhraní a pak ho tak i stahovat je šílenství.

A pokud by to mělo být opravdu několika gigabajtový balík dat tak to nahraju na DVD nebo flashku a pošlu to poštou doporučeně :D Adresát to bude mít druhý den já ani on nebudeme muset trávit několik hodin posíláním a stahováním dat u internetu :D

Ve všech případech data samozřejmě zašifrovaná, to je jasné. Ale posílat to na nějaká pofidérní webová úložiště, nebo za to ještě platit přes SMS? To opravdu ne...

presne tak!

Všechno z toho, co zmiňujete, jsou použitelné metody, které mají výhody a nevýhody.

Ne každý má možnost FTP použít (nebo jako BFU o této službě ani neví). Služby založené na HTTP protokolu jsou dostatečně intuitivní, protože uživatelé mají potřebný „nácvik“ z příkládání příloh k mailu ve svém webmailu.

Posílání souborů na datovém nosiči klasickou poštou znamená zaplatit poštovné, zajít na poštu nebo k nejbližší schránce a na straně příjemce nejméně jeden den čekání, bez garance doručení do druhého dne. Anebo zaplatit dražší expresní nebo kurýrní službu.

Stáhnout jeden větší soubor z internetové úschovny (víc souborů může odesílatel zabalit do jednoho) za předpokladu, že vám nepadá připojení, není problém, během stahování můžete dělat svou běžnou činnost dále. S HTTP uploadem velkých souborů osobní zkušenost nemám, zatím jsem to vždy řešil SCP nebo SFTP uploadem na náš WWW server; internetové úschovny využívám často jako příjemce.

Pozor - přijde nečekané odhalení. Ne všichni žijí v Praze!

A s tím trochu souvisí to, že mimo Prahu (velká města) to taky není s rychlostí připojení žádná sláva a pořád může být výhodnější to vypálit / nahrát na flashku a poslat poštou / po někom, než to půl dne uploudovat přes ADSL 512 1:50 a druhou půlku to bude někdo tahat k sobě. Obojí za cenu, že si nikdo z firmy nestáhne ani kurzovní lístek.

Bohužel, IETF v této problametice totálně zaspalo. Chtělo by to RFC, které by umožnilo posílat mailem velké soubory. Ať přímo, nebo s uložením někam na server a stažením na základě klíče poslaného mailem...

Z hlediska uživatele by to mělo ideálně vypadat tak, že prostě k mailu přiloží soubor a nemusí řešit, že do téhle velikosti se dá přiložit k mailu, do jiné ho musí někam nahrát a poslat jen odkaz.

Na to není potřeba žádné RFC. Tohle může implementovat jakýkoliv e-mailový program: 1) velký přiložený soubor nahraje na nějaký server dostupný přes HTTP (je jedno jak - přes FTP, na jabber disk, něco jako dropbox, MS Sky Drive ...) a 2) odkaz na soubor vloží na konec těla e-mailu.

Příjemce pak klikne na odkaz (obsahující třeba nějaký hash pro zabezpečení), a žačne stahování přes HTTP. Závěr: nároky na příjemce žádné (jen možnost stahovat z HTTP adresy), implementace u odesílatele libovolná podle možností. Proč to ještě nikdo neudělal a nerozšířilo se to? Nejspíš proto, že není nějaké obecně (nejlépe zdarma) dostupné online úložiště.

Možné vylepšení, ke kterému by bylo vhodné mít RFC by spočívalo v tom, že se k e-mailu přiloží odkaz na soubor s nějakým speciálním content-type, a e-mail klient příjemce by ho transparentně zobrazil jako "obyčejnou" přílohu.

No právě, není nic "obecně rozšířeného", protože to není nijak standardizováno. Na každé úložiště se nahrává jinak a MUA obecně netuší, na jakém URL se příloha objeví. Tedy možnost atomatizace jen pro konkrétní případy, obecně nula.

Chtělo by to, aby to byla featura SMTP protokolu / serveru. MUA by řekl SMTP serveru "mám tu velkou přílohu, posílám" a SMTP server by mu odpověděl "OK, bude přístupná na tomto URL". Pak by stačilo jen správně nakonfigurovat SMTP server (což udělá admin, to jde mimo BFU) a mít klienta podporujícího RFC a vše by fungovalo.

SMTP server by uložil a poskytoval přílohu sám, nebo by se mu dal nakonfigurovat FTP server, kam by to hodil...

Mohl by na to být speciální content type nebo tak něco, MUA nepodporující RFC by měli v textu odkaz, MUA RFC podporující by mohli přílohu automaticky stáhnout / nějak to uživateli "hezky" zobrazit atp.

Potíž je v tom, že tohle by nefungovalo pro "legacy" SMTP servery (ty, co to ještě nepodporují). Teoreticky by stačila podpora prvního SMTP serveru, přes který e-mail posíláte. Málokterý poskytovatel vám ale bude jen tak poskytovat prostor o kapacitě stovek MB jako úschovnu.

Ale třeba takový Gmail by to mohl implementovat i pro SMTP protokol, a případně to může být transparentní pro klienta, který by neuměl tuhle signalizaci.

Ale momentálně je zásadně jednodušší tohle implementovat ve webovém rozhraní, kde lze uploady velkého objemu a mnoha souborů řešit elegantně pomocí Flashe nebo Javy - funguje to fakt hezky. Použít jednou za měsíc při odesílání "velkého e-mailu" nějakou dobře udělanou úschovnu, to není problém".

Sám to mám takhle udělané na hostingu: 1) otevřu v browseru URL ze záložky, 2) kliknu na "nahrát soubory", 3) vyberu adresář k nahrání, 4) vidím průběh uploadu, 5) do schránky se mi vloží link, který dám do těla e-mailu. Je to prostě jednoduché, a v integraci do mail klienta nevidím moc výhodu.

Ano, stačila by podpora prvního serveru, tedy typicky firemního, eventuelně u mého poskytovatele.

Na starých SMTP serverech by to samozřejmě nefungovalo a muselo by se to řešit jako doteď, ale znamenalo by to zachování stávajícího stavu, ne zhoršení.

Jenže ne každý má podobnou aplikaci na hostingu. Ona je vpodstatě jednoduchá, komplikovanější věc je, "kdy smazat uložený soubor". Adresát si přečte mail, soubor stáhne, ale pak ho omylem smaže, k mailu se po nějaké době vrátí a soubor už stáhnout nejde. Zde by byla také malá výhoda standardizace - MUA by mohl přílohy stahovat automaticky.

No sice pořád nechápu k čemu potřebujete standardizaci v IETF, ale pokud máte ten pocit, tak navrhuji, že byste to I-D napsal. IETF není žádný magický mozek lidstva a pokud tu práci někdo neudělá, tak se sama nestane. I-D můžete podat jako individual submission nebo si najděte nějakou pracovní skupinu (tak od oka by se to mohlo hodit do yam).

+1 :-)

Obavam se, ze dochazi k nejakemu totalnimu nedorozumeni na tema, co je to vlastne IETF a jak vznikaji standardy. Neco podobneho jako kdyz se v diskusi o IPv6 objevilo, ze ho IPv6 navrhovali akademici.

Ale SMTP s velkými soubory nemá žádný problém. Jediná komplikace je, že base64 kódování nafukuje velikost dat.

Další podstatná komplikace je ta, že si SMTP neumí rozumně poradit s přerušením spojení. Takže když se odešle 150 MB a spojení se rozpadne, musí se příště začít zase od začátku.

To určitě není neřešitelný problém :-)

To není, i když vzhledem k tomu, že může existovat mnoho cest, přes které servery se e-mail bude posílat, bylo by to docela komplikované. Ale než to hackovat do SMTP a do programů, to je jednodušší použít nějaký jiný protokol, který už to umí.

A který protokol umí provést úkol "tenhle velký soubor přenes člověku s touhle emailovou adresou"? Řekl bych, že žádný ;-)

Nevím odkud máte informaci o tom, že "většina" serverů odesílá emaily sériově. Má zkušenost naopak říká, že většina SMTP serverů je standardně konfigurována na paralelní odesílání.

IETF totalne nezaspalo. IETF se neridi tim, co chteji uzivatele, IETF se ridi tim, co je dobre pro sit.

Montovat dalsi funkcionalitu do SMTP je cesta do pekel - napriklad kvuli overheadu nebo principu nekontrolovaneho "store and forward".

Nebo Ty bys rad, aby Ti chodily desetimegabajtovy spamy? Ja ne.

Navic ... IETF je otevrena platforma pro diskusi, ale nejak si nevzpominam, ze bys v nejake z WG toto tema otevrel. Samozrejme nesleduju vsechny ... rad se budu mylit. V takovem pripade Ti patri moje hluboka a uprimna omluva.

Samozřejmě posílat přímo v mailu není ideální, ale v tom uložit bokem a poslat odkaz nevidím problém (takže 10M spamy by nechodily). Koneckonců, je to totéž, jako se děje už dnes, jen by to bylo více uživatelsky přítulnější.

Ad IETF: Bohužel, ani já nejsem dokonalý a nemám kapacitu napravovat všechny nedokonalosti tohoto světa ;-)

Dokonaly nejsme asi inkdo, tim mene ja.

Ale kdyz uz kritizujes nejakou organzaci, mel by sis o jejim fungovani neco zjistit :-)

jinak riskujes, ze budes pusobit ponekud komicky.

Aha, odtud vítr vane :-) Mohu Tě ujistit, že můj první příspěvěk nebyl míněn jako kritika IETF, ale jako idea, jakou cestou situaci zlepšit.

Mimochodem, _vážně_ si mysíš, že se někdo v IETF bude seriózně zabývat návrhem člověka, který nemá v rámci IETF žádnou historii a ani není významným členem nějaké velkého komerčního nebo akademického subjektu z oboru? Nadto když ten návrh řeší problémy, které mají prakticky výhradně BFU a techniky, tedy členy IETF moc nepálí? ;-)

IETF jsou pracovni skupiny. A v pracovnich skupinach se seriozne zabyvaji i vetsima kravinama nez je ten Tvuj.

Samozrejme, pokud mas nakou historii, tak je to lepsi.

Prosim zastav dalsi diskusi na toto tema, dokud nezjistis, jak IETF funguje. Nijak netouzim byt IETF verozvestem :-)

"IETF totalne nezaspalo. IETF se neridi tim, co chteji uzivatele, IETF se ridi tim, co je dobre pro sit."

A o tom, co je dobre pro sit, rozhoduje IETF... :-) To zni skoro jako z Orwella.

Nastesti clenem IETF je kazdy, kdo se za clena IETF povazuje :-)

Data do nějakých 200 MB posílám FTP na svoje WWW (to co nechci aby bylo úplně veřejné do adresáře s řízeným přístupem a šifrované). Ale pokud jde třeba o fotky z nějakých akcí, které bude stahovat spousta lidí, nebudu si plácat traffic a pošlu to na nějakou úschovnu. U dat v řádu GB bych to taky poslal na DVD.

nahrávat něco na CD nebo na DVD? posílat "analogovou" poštou? proboha to je návrat do středověku!!!

Jak rika jedno stare moudro - nikdy nepodcenuj datovou prenosovou kapacitu kamionu nacpanyho disky nebo paskami v pripade.