yEnc čili za e-mail rychlejší

Nemohl by tady někdo podat výklad o jednotlivých typech kódování (´jak fungují, čím se liší atd.)? A nebo o fungování emailu obecně? Nebo posytnout odkaz na tyto informace?

Díky. Snad nejsem sám, kdo by se rád přiučil .

Opravdu kvalitni algoritmus - vcetne deleni do casti, korekcni soubory atd... nabizi tento program 7plus

Pouzival jsem ho jeste kdys na Packet Radiu  umi samozrejmne i dlouhe soubory.

http://home.t-online.de/home/dg1bbq/7plus.htm

      Michal Poupa

Jasne ze se da usporit hodne nepouzivanim formatu HTML (pokud to neni nutne), ale dalsi megauspory by prineslo lepsi pouzivanim RE a FW: na co tam proboha nechavat "original message from .........." nebo na obrovsky mail (obsahove) posilat RE "souhlasim" a k tomu pripojit cely ten megamail. Kdyz to vsechno vnorime (nekolikanasobne RE nebo FW), pripojime ke kazdemu vnoreni "odchozi zprava neobsahuje viry ...." a navic pouzijeme HTML, tak pomer informaci ku obsahu je jiste zajimavy

Mno jo, ale tohle uz neni o programech, formatech a serverech, ale zase o tech natvrdlych uzivatelich!

Ne, ze bych s Vami vyslovene nesouhlasil, ale to je spis pripad preposilani (odpuste mi ze to tak popisu) kravinek (obrazky, filmiky, MLM, XXX, annonce...). Musite, ale vzit v uvahu i pripady kdy probiha nejaka napr. obchodni komunikace formou mailu avsak onoho casu mimo vas a dostanete opozdene tyto informace k precteni (formou Cc: .. ap) lhostejno jestli z duvodu pochopeni problemu, zapojeni se do diskuze nebo nejakeho zpetneho dokazovani. Pak jsou VELMI dulezite prave informace typu "original message from" ap, ktere by tam pravda vzdy byt nemusely. Take je spousta uzivatelu, kteri si nevytvareji archivy mailu. Zpravu proste prectou a okamzite ji mazou aby meli 'cisty stul'. Kdyz takovemu cloveku poslete pouze souhlasim, vetsinou nepochopi ceho se to tyka. Je ale samozrejme nesmysl forwardovat uplne cely obsah. Postaci ocitovat puvodni text. Souhlasim, ze za zamysleni stoji jestli je napr bezpodminecne nutne na konec mailu pripojovat:

---
Odchozí zpráva neobsahuje viry.
Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
Verze: 6.0.350 / Virová báze: 196 - datum vydání: 17.4.2002

nebo staci jen:

Mail is free of virus (AVG 6.0.350;196;170402)

a podobne. Ale to je podle mne boj s vetrnymi mlyny :o(

Protože na neefektivnost 6ti/7mi bitového kódování se už přišlo aspoň před 10ti lety , řadu let existují rozšíření SMTP protokolu, které to řeší. Viz. např. tato klíčová slova EHLO odpovědi:

8BITMIME, BINARYMIME.

Zájemci o podrobnosti doporučuji RFC dokumenty. Při psaní vlastního mail serveru jsem z nich taky vycházel..

Za přístup ke kvalitnímu, kompletnímu Usenetu a zejména jeho skupině „alt.*“, případně ještě častěji „alt.binaries.*“, se dnes platí

Tak to je mi těch uživatelů fakt líto... Existuje řada jiných, neplacených a plně funkčních sítí pro sdílení dat, která navíc žádné problémy s kódováním nemají...

Jo a co se týká velikosti emailů (kódování, HTML...), tak si myslím, že to je úplně jedno, neboť větší soubory (10M+) posílat emailem je scestnost. Od čeho je FTP, ICQ, MSN Messenger apod?

...prvních 127 znaků kompletní ASCII sady ...

No to jsou mi veci, pokud ja vim tak kompletni ASCII (American Standard Code for Information Interchange) obsahuje "jen prvnich 128 (pocitano od nuly :) znaku" a nic vic. Tyto znaky jsou u vsech kodovani stejne, protoze je to proste standad. Dalsi znaky (diakritika, ramecky a pod) jsou soucasti jednotlivych znakovych sad. Tyto znakove sady obsahuji znaky ASCII, ale ASCII neobsahuje rozsirujici znaky techto sad. Na tomhle nic nezmeni ani autor clanku... :)

Vas udiveny Skrew

Heh, kdyz uz sme u te uspory dat co protecou sitovkou nez se mi to obevi na monitoru, tak by me mile Zive zajimalo, kolik megabajtu reklam nasosam z Vaseho webu ....

window.open=PrxRealOpen;
Kdyby poštovní klieti byli schopni provádět komprimaci souborů... Drtivá většina příloh je posílána ve formátech pdf, rtf, doc... Přitom by to nebylo tak složité a úspora by mohla být mnohem větší.

Možná by se tento přístup mohl rozšířit i do http protokolu, tj. na server by se umístili komprimované soubory (ano, obrázky už komprimované jsou), které by následně dekomprimoval browser. V podstatě by to šlo udělat například přes lokální chache, než by se MS rozhoupal...

Jen by bylo nutné vyvinout jiný styl komprese - tj. aby stačilo pro dekompresi načíst jen část souboru (tj. nemuselo by se čekat, až se stáhne celá stránka).

Většina toho, co chci říct, už tady zazněla, takže souhrnně:

Dnes už není problém přenášet poštu 8bitově - jak češtinu, tak často i přílohy (servery už dlouho podporují 8BITMIME nebo dokonce i CHUNKING - viz RFC 2821a související). Pokud se na cestě narazí na starší server, stačí zprávu překódovat.

Na kompresi příloh jako takových se dívám skepticky  - těžko půjde komprimovat GIF, JPEG nebo třeba PDF. V definici HTTP už komprese je, stačí, aby ji podporoval klient i server (např. Apache to umí). Ale v případě modemů by to stejně nepřineslo příliš velký užitek, transparentní proudová komprese je dostatečně účinná.

Význam yEnc však vidím z hlediska ekonomického - tedy pokud se účtují přenesená data. Tam by se opravdu mohlo dosáhnout významných úspor.

IIS kompresi, samozrejme, umoznuje (GZIP a DEFLATE).

http://support.microsoft.com/default.aspx?scid=kb;CS;q255951

Komprimace HTML stranek je skutecne prima záležitost. Jestli vytváříte weby v PHP, stačí v php.ini nastavit

zlib.output_compression = On
extension=php_zlib.dll

a váš web jde do světa zkomprimovaný a mnohem rychleji. Někdy to dělá skutečně divy. Komprimovaná stránka je například tato: http://www.w3.org/People/Raggett/tidy/

Divy to opravdu dela. Ta stranka se mi nenatahla vubec  Tak takovy web mit opravdu nechci

ale to mas problem jinde - pokud prohlížeč komprimované stránky nepodporuje, tak se stránka posílá normálně.

Pokud mate na vobu hodne textu, tak asi ano, ale pokud tam mated dostatecne mnozstvi obrazku (nemyslim nekomprimovane bitmapy  ale treba jpeg apod.) tak moc neusetrite  Docela for by byl komprimovat download *.zip souboru, to by byla uspora

Prave ze jpeg už ZIPem nezkomprimujete. Ekeftivní je komprimovat právě HTML - a nemusí tam být vůbec žádný text...

A ještě jeden fakt je třeba si uvědomit. Odmyslíme-li si čas cesty dopisu od příjemce k SMTP serveru a čas po který si ho budou předávat servery mezi sebou, tak můžeme zjistit, že nejvíce času zabere zpracování dopisu na koncových serverech. V současnosti je totiž nutnost, aby koncové servery prováděly antivirovou kontrolu a může se stát, že dopis s několikamegabajtovými přílohami se takto zdrží i o několik desítek sekund!

No a?

Dobře, ale to je přece úplně něco jiného: to není otázka času, ale výpočetního výkonu (většina serverů stejně jede na pár procent svého výkonu), zatímco datový průtok je věcí kapacity linky. S tím druhým jaksi nic neuděláte (pokud nejste multimilionář, který si domů natáhne gigabit; pak vás nějaký yenc samozřejmě nemusí tankovat).

Dnes jsou všechny přílohy mailů kódovány, takže server, pokud chce provést avir kontrolu, musí je dekódovat - tak jako tak. Takže je celkem jedno, jak jsou kódovány, rozdíly ve výpočetních nárocích na zakódování/dekódování nejsou přece významné.

Tenhle clanek musi byt kolektivni dilo. Tolik nesmyslu snad ani jeden clovek vymyslet nemuze:
- Ze je nejpouzivanejsi uuencode, to bych se dost hadal. Dnes snad kazdy mailer defaultne pouziva Base64.
- U base64 je nafouknuti o 33% tim, ze na zakodovani 6 bitu potrebuje 8. Plus neco malo na konce radku a statickou rezii.
- Takto se neprenasi vsechny ceske testy. Normalni mailery pouziji "quoted" notaci, ve ktere jsou US-ASCII znaky zachovany a ceske znaky zakodovany pomoci 3 bajtu.
- Jak poznamenal kolega, pri pripojeni pres modem jsou data komprimovana, takze to vyjde vpodstate nastejno, jestli se posila binar nebo kodovana data. Dela se to na linkove vrstve. Ale treba pres ethernet se data nekomprimuji.

Ad tahle veta z prispevku:

- Jak poznamenal kolega, pri pripojeni pres modem jsou data komprimovana, takze to vyjde vpodstate nastejno, jestli se posila binar nebo kodovana data. Dela se to na linkove vrstve. Ale treba pres ethernet se data nekomprimuji.

K tomu, co je standard se nevyjadruju, takze neoponuju, ale s tou komprimaci na urovni linku to je docela slusnej kraf. Prirozene, ze kdyz toho ma modem prenest mene, prenese toho s komprimaci jeste mene. Takze uspora urcite je, nevyjde to na stejno :]. Ethernet neni o tom, aby zdrzoval. Je rozdil mezi rychlosti prenosu modemu a sitovky :).

Ony jsou tam ty komprese dve. Jednu dela PPPD (pokud ho pouzivame - coz je typicky pripad), druhou samotny modem. PPPD je podle mne zjevne linkova vrstva.

Rád se k vašim "nesmyslům" vyjádřím:

- uuencode: je nejčastějsí v Usenetu, a o něm především ten článek je. Jak to je s e-mailem: drtivě převažuje OUtlook/Outlook Express. Jak se to v nich kóduje, předkládám sám dobře víte.
- nafouknutí: je u různých kódování různé, od třetiny (plus ovšem režie, která zase tak malá není) až po 100%
- české texty: bavíme se především o binárních datech, ty jsou zcela podstatné pro debatu o úsporách velikosti
- komprimace dat: bavíme se o nafukování souboru při kódování. Je jasné, že kódovaný, stejně jako nekódovaný binární soubor se dá dále komprimovat, ale to už je úplně jiná debata. Tento článek není o WinZipu...

Pro diskusi by jistě bylo lepší, kdybyste ubral na "nesmyslech", které se samozřejmě žádnými nesmysly neukáží, a diskutoval korektně. Ani ostatní čtenáře příliš nezajímá, jak moc si snažíte hýčkat svoje ego a nejvyšší inteligenci na celém českém Internetu.

- Ten clanek je o usenetu? A proc ma tedy nadpis "yEnc čili za e-mail rychlejší"??? Co vim, tak Outlook pouziva base64.
- Nafouknuti - v extremnich pripadech quoted az o 200% Ale typicky je to u dostatecne dlohych souboru tech cca 35%.
- Clanek je o e-mailech. Ma to jasne uvedeno v nazvu a priklad kodovani je opet textovy. A vetsina dopisu co znam zadna binarni data neobsahuje.
- Komprimace dat: Byla to reakce na tvrzeni "Kdyz dopis zakodujete, budete ho modemem stahovat o 40% pomaleji". Nebudete, protoze ho PPP a pripadne i modem zakomprimuje.

Pro diskusi by bylo jiste lepsi, kdyby jste ukazal kde se mylim misto narazek na me ego nebo tvrzeni ze clanek je o tom a tom.

P.S.: Kdyz uz jsme u te velikosti, take si myslim, ze nejlepsi by bylo, kdyby si lide prestali myslet, ze nejlepsi zpusob jak napsat dopis je ho napsat ve wordu (samozrejme bez jakehokoli formatovani) a poslat jako prilohu.

Musím uznat, že titulek je "novinářský", záměrně poukazuje na e-mail (který každý zná), nikoli na Usenet (který až tak známý a využívaný není - na škodu, ovšem). Pokud by tam byl usenet, nezaujalo by to tolik čtenářů - někdy, pokud chcete čtenáře dostat k tématu, který je pro ně atraktivní, zajímavý, je potřeba poukázat na to, co sami dobře znají. Článek sám je především o kódování v prostředí Usenetu a o novém fenoménu yEncu s tím, že v prostředí e-mailu je tento typ kódování také v budoucnosti použitelný.

Jinak v Outlook Expressu se často setkávám s quoted printable, ale to je celkem jedno. Je jistě pravda, že většina e-mailů neobsahuje binární přílohy, jenomže většina emailů na počet neznamená  většina trafficu. Stačí jedna megabajtová příloha (a že mě takových dneska došlo...) a je to víc než 200 běžných mailů. O to tady jde.

K té komprimaci. Možná se někde mýlím... Když vezmu obrázek (kupříkladu) a převedu jej např. přes uuencode do ascii textu, a pak obě verze zkomprimuji stejným prostředkem (kupř winzipem, pro jednoduchost), tak budou stejně velké? Myslím, že ne.

opravdu nebudou stejne velke ... ten prekodovany a zkomprimovany bude mit o 0.5% vice... zkousel jsem to na 180kb jpegu zabalen zipem se standartni kompresi ...

Jde o to, ze soubor v uuencode je sice o 33% procent vetsi, ale ma mensi entropii, proto obě verze budou po komprimování skutečně stejně velké. Jednoduše řečeno - obě verze mají v sobě stejné množství informací, jen jinou "hustotu". Ve skutečnosti bude soubor uuencode o něco málo větší, je to dáno tím že žádný komprimační program není absolutní.

Takže v tomto konkrétním případě je přínos nového kódování skutečně minimální.

nebo taky jeden cesky znak pri UTF-8 a quoted-printable da 6 znaku. Na druhou stranu, koho to tlaci?

Podle me lze vyrazne usetrit, kdyz si lidi v Outlooku vypnou odesilani emailu ve formatu HTML. Podivejte se na klasickou ukazku z Outlookoveho emailu dole, spicate zavorky jsem nahradil hranatymi:

[DIV][FONT face="Arial CE" size=2][/FONT] [/DIV]

Dobry ne? Prijemce zpravy se dozvi, ze na danem radku je JEDNA MEZERA! O ktere si myslim, ze vznikla tim, ze autor zmackl klavesu "enter", protoze takovych radku byva standardne vic pod sebou.

Tudy si myslim, ze vede cesta k usporam.

O tom, že posílání HTML verzí je není pochyby. Ale vysvětlujte to lidem co o tom nic nevědí!

Nebo tem, kdo to HTML v mailu _POTREBUJI_, protoze _POTREBUJI_, aby mail vypadal dobre.

To je převratná myšlenka, všechno se bude vysvětlovat jenom těm, kdo už to ví!
To bude rázem volných míst na všech školách...

(sorry, vypadlo jedno důležité slovo)

O tom, že posílání HTML verzí je *CENSORED* není pochyby. Ale vysvětlujte to lidem co o tom nic nevědí!

Kdyz mi prijde mail, jehoz jedinym obsahem je HTML priloha, automaticky jde do kose Ja jim taky neposilam .dvi

 stejně je to v 99% stupidní MLM nebo XXX nabídka!

Jooo, kdyby to XXX bylo skutecne free, tak jak vetsinou inzerujou, a nechteli po me cislo kreditky "na overeni veku", tak proc ne - ale takhle si radsi stahnu password list. Pouzivat "Credit Card Generator" popravde receno nechci...

Dovolím si s vámi zásadně nesouhlasit. Ani odborník jako vy nesmí z úst vypustit věci jako že "HTML v mailu je *censored*", aniž to dovodí silnými argumenty. Víte stejně jako já, že toto téma je velice diskutované - tj. existují závažné argumenty pro a proti. HTML v mailu podporují nejužívanější klientské programy u firem, které - světě, div se - psané standardy obvykle dodržují (někdy také ne).

Za několik let si budeme posílat nejen formátované maily, ale také maily zvukové a obrázkové - tj. místo mailu zapnete kamerku s mikrofonem nad počítačem a řeknete "čau péťo, zalej kvítka za oknem". A místo 20 bajtů internetem proteče 20 megabajtů. Who cares? Naprosto vám neberu právo být zásadním a nesmiřitelným odpůrcem html v mailu; měl byste ale uvést, proč by ani všichni ostatní neměli HTML v mailu používat. Jestli vám (osobně, ve vašich mailech) stačí neformátovaný mail s "cestinou" - budiž. Mě ne - já chci psát maily jako dopisy, s "kudrlinkami a obrázky", a nejsem v tom sám.

Jsem si vědomý především bezpečnostních rizik HTML (DHTML atd.) formátu - to je jasná věc, ale ne nepřekonatelná. Velikost je zástupný argument; drtivá většina trafficu jsou binární data (přílohy atd.), ne mail bodies.

Tam kde je to zapotřebí, prosím. Ale mít to paušálně zapnuté a posílat v tom kdejakou informaci (a i třebas zprávu o přečtení mailu), to je opravdu  scestné. A s "cestinou" to přece nemá nic společného.

Ze jo. Ale ono treba Zive by krasne vypadalo v Gopheru, proc proboha vsichni debilove pouzivaj HTML ktery je velky a ma spoustu bezpecnostnich problemu? Proc proboha vsichni nevedej to co vim ja? Zpravodajsky weby se bez grafiky a narocnyho formatovani obejdou a presto je lidi pisou v HTML. Natoz ti silenci co chtej texty balit do XML tagu popisujicich logickou strukturu dokumentu (a na e-mail se tohle zrovna hodi docela dost, umozni to zpracovavat informace automaticky podstatne lip nez dneska), to sou uz naprosty hovada, ze jo ;)

Zcela vyjimecne naprosto s nazorem p.Hlavenky souhlasim

Myslim ze moznost posilani E-mailu v HTML formatu je skvela vec, akorat:

a) nememela by byt zapnuta implicitne
b) nemela by se zprava posilat jako attachment(priloha), ale inline

OPRAVDU nemam problem s tim kdys mi nekdo takhle posle zpravu - to ze je to 20KB misto 5KB plain textu me opravdu nerozhazi, i na modemu je to bezpredmetne.

To co mne dokaze ale skutecne nas..at je kdys nejaka krava (nic proti zenskejm obecne) pise maily ve Wordu a odtamtud' je posila tlacitkem "Send as E-mail", pochopitelne jako prilohu Tak dostanete E-mail s 40KB prilohou .DOC (navic jeste nafoukla kodovanim MIME), otevrete ji a tam je 1 radek (!!!) textu - potvrzeni schuzky apod.

Tak tohle podle mne je (CENZORED) (CENZORED) (CENZORED) !!!!!

Ne jenom ze ten mail je 100krat vetsi nez data v nem obsazena, ale navic se clovek muze uklikat jak magor nez se k nim dostane a navic jeste musi mit ten Xindl M$Word nainstalovany. (Ja vim, ja vim, jde to i WordPadem, ale stejne je to (CENZORED)(CENZORED))

Kazdy ma pravo na odesilani HTML emalu, nicmene ja osobne tyhle emaily rovnou mazu .... beztak je vetsinou muj mailer zobrazi tak, ze nejsou k precteni, nebo minimalne vypadaji mnohem hnusneji nez autor zamyslel (Ne, Utlouka nepouzivam a pouzivat nehodlam) .....
Mozna by stalo za to pridat do ruznych freemailu kde maj spam filtry podle odesilatele nebo obsahu zpravy pridat i filtry na content-typ (if content-type=text/html smazat). Asi jim pripomenu, jak by takovy filtr byl uzitecny :o)

P.S. : Proc mi zive nuti na psani prispevku jakysi DHTML editor, ktery v Opere nefunguje? Nemuzete udelat aby defaultni nastaveni bylo textove pole?

ty si ale pitom*c, kdyby sis v Opere nastavil Identify as Opera, tak bys tam to textový pole měl

Bud jste student nebo kecate.
Spis bych to ale videl na studenta. Az dostudujete a prijdete do normalniho zivota, zjistite ze vyhodit kazdy mail ktery neni podle Vasich naroku (mimochodem, v komercni sfere by jste vyhodil asi 90 procent mailu) je nejrychlejsi cesta pod most, protoze by jste nejspis zkrachoval.

Nebo je to hobit             

Jeste lepsi je kdyz nekdo misto textu v emailu posila .doc - to vracim okramzite zpatky.

A ja lidi co mi na dalnici neudelaj misto kdyz chci menit pruhy rovnou strilim. Proste vsechno bude podle me protoze ja sem ten nejchytrejsi

Autor napsal informace o kódování pošty dost povrchně.

Existence řídících znaků není totiž jediný důvod, proč se používá kďování e-mailu (a mám na mysli skutečný e-mail a nikoliv binární přílohy). Některé poštovní systémy cestou totiž mohou být ještě zastaralé a propouštět pouze 7 bitů - kdysi totiž unix opravdu neznal 8-bitová písmenka a prakticky ve všech programech se vyskytovaly instrukce, které textová data "pro jistotu" ořezávaly na 7 bitů. Dnes je snad už většina opravená a pokud se poštovní servery navzájem dohodnou že oba umějí přenášet 8 bitů tak dopis skutečně přenesou 8-bitově (a třebas i provedou dekódování z Base64 nebo QuotedPrintable). Z toho ale vyplývá, že pro nový způsob nejde jen upravit poštovní klienty, ale že je nutno upravit i software na poštovních serverech, aby dokázaly v případě nutnosti "nově" kódovaná data přebalit do 7-bitového formátu!

Máte zcela pravdu. Nechtěl jsem se do e-mailu podrobněji pouštět, to by byl článek na pět stránek. yEnc je zatím doma jen v Usenetu a ještě tam nějakou dobu pobude - je to ostatně v článku uvedené. Co se týká e-mailu, tak jsem názoru (a je to v článku též), že i zde je značná možnost úspor použitím tohoto typu kódovacího mechanismu, a zcela souhlasím s vámi, že důvod, proč to tak brzy nebude realizováno, je existence zastaralých poštovních systémů.

yEnc pres zastarale postovni systemy take projde, ale jedine tim zpusobem, ze se zakodovana data prevedou do BASE64, cimz pouziti yEnc ztraci veskery smysl. Pridavat do postovniho serveru podporu pro kodovani yEnc take nikdo nebude - to je lepsi pridat podporu pro jiz davno existujici standard pro prenos binarnich mailu bez jakehokoliv kodovani - BINARYMIME (RFC 3030). Proto si myslim, ze yEnc se v emailu nikdy pouzivat nebude a zustane zalezitosti warezovych skupin na Usenetu.

pokud vim, tak stejne vsechna komunikace tcp/ip je na urovni paketu komprimovana a na disku, kde je ulozena, muze byt komprimovana take. Opravdu nechapu vyznam tohohle "programu"

"nojo - pravda - ten Nemec to ma cely blbe a celej usenet mu pekne naletel ... bez to nekam napsat, myslim, ze bys mohl beyt prezidentem internetu" ;o))

nic nevis, jinak bys takovy nesmysl nevypustil z klavesnice

Pozor, nedělejte častou chybu jako mnozí jiní: kódování a komprimace jsou dvě naprosto různé věci.

no ja bych spis rekl, ze komprimace je specialni pripad kodovani, kdy vysledna posloupnost ma mensi velikost nez puvodni data.

Pro informaci zajemcum o tu nejlepsi cast internetu

http://www.newzbot.com je mimo jine vyhledavac public news serveru, trideny podle jednotlivych newsgroup a poctu prispevku v nich. Neni sice dokonaly, ale urcity obraz da - vetsinou je stejne lepsi nez news server u isp...

Sou aspon z meho pohledu jednou ze zakladnich sluzeb ISP. A jejich kvalita je jedna ze dvou veci co me drzi u myho ;)

Ake je jeho URL (nntp://???)? Ja pouzivam od ISP len default gateway, ale niekedy by som radsej pouzil vlastny (kvoli spolahlivosti). Aky dovod by som uz potom mal na dalsie vyuzivanie ISP, ze ano...

Naspat k clanku... este stale sa pouziva BinHex? Ved ten nafukuje data o 100% Kedze email vacsina ludi nepouziva interaktivne, 33% navrch (Base64) nie je podla mna az tak vela, aby sa to nedalo vydrzat. Ale inac som za kazde zrychlenie, ak to nepojde na ukor stability, resp. spolahlivosti.

Daemon, Ty sa na vsetko kukas z uplne ineho sveta

33% je fakt vela. Ja viem, ze na prenasanie suboru by sa malo pouzivat radsej ftp, ale su ludia, ktory pouziju aj tak mail...

Podla mna, ked sa da pred subor dat hlavicka, tak nemoze byt problem pouzit nieco, co pouziva konstante zvacsenie prenosu. samo, potom by sa museli servre radikalne zmenit... ale nejak by sa to uz mohlo zacat menit, aspon v linuxe )

*Sho*

< META http-equiv=REFRESH content=0;URL=http://www.leo.cz>

 A mas po ptakach, Mufe.

UUencode, jestli se nepletu, zvyšuje objem cca o 42%; nejde jen o kódování, ale i o různé přidané znaky (umělé odřádkovávání, deklarace na začátku a na konci). Jde hodně o to, kdo to používá a jak je připojen. Jestli máte dial-up a chcete stahovat 600 MB, a místo toho musí protéct linkou 1 000 GB, tak je to tak o 16 hodin stahování víc - spočítejte si cenu sám

Když budu chtít tahat 600 Mb, použiju nějaký inteligentní protokol (např. rsync), který nebude oplývat tolika balastu. Původní určení tohoto kódování je na přenášení pošty = textu. Bylo to rozšířeno o binární (=zakódované) přílohy, ale nic to nemění na tom, že velké objemy by se měly spíš někde vystavit a poslat odkaz, než tím zatěžovat mail servery.

Ked stahujem 600 MB, nafuknuty objem dat je 1000 GB (1 tera-byte)? To by bol pekne nafukovaci algoritmus Mne to vychadza na nejakych 840 MB, ale to nie je az take podstatne. Ale ako uz spomenuli predo mnou, stahovat obrovske subory cez email je blaznovstvo.

nntp://news.earthlink.com kdyz se chces bavit ;) Stejne si hlidaj IP adresy, takze budes muset spoofovat abys z nich neco dostal. To ze v tvoji zemi kde se vsechno dela nejlip neexistuje poradnej ISP by ti melo dat dobrej duvod k zamysleni.

Ty mi uz vazne pripominas mentalitu typu Baywatch a Beverly Hills 90210 dokopy. Teraz hovoris mudro ako keby v USA boli vsetci Inet provideri spolahlivi. Ja som toho nespolahliveho zamenil, momentalne som so spolahlivostou spokojny a s rychlostou taktiez (3 Mbit downstream, 500 Kbit upstream). Tak sa prestan tvarit, ze zijes na pupku sveta. Zamyslat sa budes Ty, ked spolu so vsetkymi Amikmi budes nuteny pouzivat Passport ako personal ID a namiesto usilia vlozeneho do kvality software-oveho produktu bude Vasa vlada investovat miliony, aby ste chytili kazdeho adolescenta, ktory sa Vam vlame do sukromia.