Nechcete si vydělat úpravou KMAILu?

20.12.2006 22:01 | Přečteno: 1656×

Tento blogpost je o nabídce zasponzorování implementace nové vlastnosti KMailu

Jako intenzivní uživatel KMailu hledám někoho kdo dokáže do této aplikace doimplementovat novou vlastnost. Pokud to bude jen trochu možné, byl bych rád, kdyby se tato vlastnost objevila přímo ve verzi KMail, kterou vydává KDE, tzn. protlačit ji do hlavní větve vývoje KMail.

O co se jedná:

Seznam zpráv ve složce by měl mít možnost přidat zobrazení uživatelských hlaviček. Dále by měl mít seznam zpráv horizontální lištu, která by uměla nad zprávami a jejich hlavičkami provádět základní aritmetické a statistické operace (sum, avg, max, min).

Příklad:

Chodí vám emailem výplatní páska. Požádáte personální, aby do výplatní pásky přidalo uživatelskou hlavičku X-Salary s výší hrubé mzdy. A protože si tyto emaily třídíte do složky Mzda, máte kdykoliv možnost získat základní agregáty Vaší mzdy. Nepotřebujete si vytvářet tabulku ve spreadsheetu, nebo údaje sečítat na kalkulačce.

Našel by se někdo s dostatečnými zkušenostmi s vývojem pro KDE a zájmem tuto věc s vývojáři KDE prodiskutovat a případně implementovat za úplatu?

       

Komentáře

[Voidless]

Hm, a co na to personalni, maji vubec poneti o tom, co je to uzivatelska hlavicka v hlavicce mailu? :)

Neni to trochu molochoidni, implementovat takovou funkcionalitu kvuli jednomu jedinemu use case?

[Jiří (BoodOk) Kadeřávek]

Personalni se v teto veci obrati na vypocetku. Jedinym use case myslis co, vyplatni pasky nebo mou osobu?

[Josef Kufner]

Výplatní pásku. Myslím, že stejnou funkcionalitu mohl obstarat nepříliš složitý script, který by to vytáhl přímo ze stávajících těl mailů. Na implementaci to bude výrazně jednodušší.

[Jiří (BoodOk) Kadeřávek]

To byl příklad, rozumíte tomu, co znamená příklad? Já samozřejmě vím, jak se dá každý specifický případ řešit.

[Kníže Ignor]

Pokud se maily ukládají nějak lokálně (mbox, maildir), pak by nemělo být těžké vytvořit skript s požadovanou funkcionalitou. Do KDE by se takto superspecifická funkcionalita (min, max, avg,...) stejně asi nedostala.

[Jiří (BoodOk) Kadeřávek]

Jedná se mi o IMAP účty. Funkcionalita až tak superspecifická není. Umožňovala by zjistit velikost složky v mailboxu, průměrnou velikost mailu ve složce, počet zpráv za dané období apod. Nicméně je pravda, že se jedná o dosud nepoužitý scénář. Použít totiž emailového klienta částečně jako databázový nástroj. Dokud to žádný klient nebude umět, nebude ani úplně zřejmé jak to jde využít. Ale dnes Vám mohou chodit emailem faktury, objednávky a je škody nevyužít možnosti přiložit ke zprávě metadata a ta umět alespoň základním způsobem zpracovat. Rozumím tomu, že funkcionalita navíc může být přítěží, na druhou stranu se může jednat o nový úspěšný scénář použití email. klienta. To by potom mohlo znamenat něco navíc oproti konkurenci. A to potřebujeme jako sůl.

[Kníže Ignor]

A nemohlo by pomoci toto? V podstatě jsem teda moc nepochopil, jak to funguje, což si ješitně vysvětluju tím, že nejsem uživatelem kmailu , ale pokud tam takovýhle filtr jde nějak dostat, tak by se dal modifikovat tak, aby neměnil položky hlavičky, ale do nějakého souboru na disku uložil potřebná data, na která by se pak aplikovaly ty statistické fce. Ale uznávám, že je to asi těžkopádné.

[rastos]

> Chodí vám emailem výplatní páska. Požádáte personální, aby do výplatní pásky přidalo uživatelskou hlavičku X-Salary s výší hrubé mzdy.

Pevne dúfam, že to je len príklad. Je ti jasné, že hlavičku mailu môže vidieť prakticky ktokoľvek?

[neaktivni]

Treba by si vedeni vsimlo, kolik mi vlastne davaj, zastydeli by se a zjednali napravu. V zapsani hrube mzdy do hlavicky vidim sama pozitiva.))

[Jiří (BoodOk) Kadeřávek]

No to mi přibližte. Já měl za to, že úroveň potřebných oprávnění ke čtení hlavičky a obsahu je stejná (anžto se nepřenášejí odděleně). Jediný rozdíl je, že obsah může být zašifrován, což se dnes běžně neděje. Ano, byl to příklad a jsem si vědom toho, že hlavičku může přečíst kdokoliv má přístup k přenosové trase nebo k jejím koncům (mta, ms). Tedy dle Vašeho vyjádření prakticky kdokoliv

[Ladicek]

A proč by to nemělo umět kreslit grafy? Mně by se určitě líbilo mít v mailovém klientu graf, jak mi roste plat. A taky by to mohlo umět dostupné mzdy proložit extrapolační křivkou, abych věděl, kdy asi tak budu mít těch vysněnejch padesát čistýho měsíčně. Et coetera, chápete kam tím mířím?

[mrzout]

Ale umoznit vytvorit virtualni slozku na zaklade definovanych pravidel s vlastnima sloupeckama a umet exportovat zobrazene sloupecky do tabulkace, to by snad umet mohlo, ne?

[Ladicek]

No, zobrazit libovolnou vybranou hlavičku by to určitě mohlo umět. A taky s ní pracovat na místech, kde se pracuje i s těmi obvyklými. Export do tabulkového procesoru? Proč ne. Ale počítat součty a průměry, hledat minima, maxima nebo mediány, to už mi přijde jako obrácený tvar té MIT(?) teze o softwarovém projektu končícím ve chvíli, kdy obsahuje mailového klienta.

[Filip Jirsák]

To by asi byla druhá možnost – implementovat do KSpreadu (proč se to nejmenuje Kalk?) e-mailového klienta

[Josef Kufner]

A nebo ještě lépe – přidat funkci: "Vybrané emaily vyexportuj do formátu mbox a předhoď to tomuhle programu na stdin."

Tím by se nic moc v kmailu nemuselo upravovat (většinu tohohle už to umí) a možnosti jsou takřka neomezené.

[Filip Jirsák]

Jenže tenhle váš návrh dává smysl a je v duchu Unixové tradice, že každý program dělá "to svoje". Původní návrh je naopak značně šílený, a i kdyby autor měl částku z výplaty opisovat každý měsíc celý život z e-mailu do tabulkového kalkulátoru, zabere mu to méně času, než takováhle úprava KMailu. Navíc bude-li chtít udělat graf, nebo spočítat třeba roční průměry, bude muset data stejně opsat do tabulkového kalkulátoru (nebo jej celý integrovat s KMailem)…

[Jiří (BoodOk) Kadeřávek]

Unixové tradice se rozhodně netýkají kancelářského software, ale systémových záležitostí a administrace. Druhou větu jste napsal zřejmě v hlubokém myšlenkovém útlumu. Podle vaší logiky by nikdo nikdy žádný software nenapsal. Detailnější rozbor proč tomu tak je nechám na Vás, ale kdybyste potřeboval, dovysvětlím. Co se týče poslední části, tak jen jedno. Existuje něco jako schránka, clipboard a pokud bude KMail umět zobrazit libovolnou hlavičku a dokáži zkpírovat do schránky sloupec hodnot této hlavičky, pak nemusím nic opisovat. A pro me za mne nemusí v KMailu žádná lišta z agregáty být, protože si to dokáži elegantně přenést do spreadsheetu. Takže, kdo chce, hledá způsoby, kdo ne hledá důvody.

[Josef Kufner]

Unixové tradice se rozhodně netýkají kancelářského software, ale systémových záležitostí a administrace.

To není až tak úplně pravda. Ale bohužel to i trochu pravda je. Najde se dost programů, které jsou jen frontendem pro specializované nástroje (lyx, grip,...), mnoho jiných je tvořeno modulárně (kontact). Nicméně i tak mají kancelářské balíky (a gui programy vůbec) sklony molochovatět víc než je zdrávo a je to obrovská škoda.

[Filip Jirsák]

Unixové tradice se rozhodně netýkají kancelářského software, ale systémových záležitostí a administrace.

Jste si jist? Unix původně vznikal pod hlavičkou systému pro zpracování textů... Ostatně kdyby se tímto pravidlem kancelářský software řídil, jenom by mu to prospělo.

Druhou větu jste napsal zřejmě v hlubokém myšlenkovém útlumu. Podle vaší logiky by nikdo nikdy žádný software nenapsal. Detailnější rozbor proč tomu tak je nechám na Vás, ale kdybyste potřeboval, dovysvětlím.

Tu větu jsme psal při plném vědomí, ovšem s jedním nevysloveným předpokladem - totiž že statistické funkce nad hlavičkami e-mailu nikdo jiný než vy nevyužije.

Co se týče poslední části, tak jen jedno. Existuje něco jako schránka, clipboard a pokud bude KMail umět zobrazit libovolnou hlavičku a dokáži zkopírovat do schránky sloupec hodnot této hlavičky, pak nemusím nic opisovat. A pro me za mne nemusí v KMailu žádná lišta z agregáty být, protože si to dokáži elegantně přenést do spreadsheetu.

Podle mne je KMail program určený pro čtení a psaní e-mailů. V poštovní programu (GMail), který používám, je pojem "sloupec" už dost zkreslený popis toho, jak e-maily zobrazuje. Pokud chcete s e-maily dělat něco jiného, než je číst, použijte nějaký filtr pro doručování, který příslušné e-maily v kopii předá skriptu, který je zpracuje, jak potřebujete.

Takže, kdo chce, hledá způsoby, kdo ne hledá důvody.

Nehledám důvody, proč to nejde, hledám způsob, jak to dělat lépe. Resp. způsob, jak dělat to, co vlastně chcete. Protože mám pocit, že chcete věc, která jde snadno řešit způsobem A, a vy řešíte, jak ohnutím několika nástrojů a drbáním se levou rukou za pravým uchem tu věc řešit složitě způsobem B.

Ale prosím, jestli chcete upravovat KMail tak, abyste mohl ručně dělat něco, co může dělat automaticky skript, já vám v tom nebráním.

[Josef Kufner]

Mnojo, takle to dopadá, když si uživatel myslí, že ví co chce.

[Jiří (BoodOk) Kadeřávek]

Co furt máte s nějakými skripty? Já mluvím o použití ve firemním kancelářském prostředí. Mluvím o možnosti přidávat metadata do emailové korespondence a pohodlně s nimi nakládat. Mít možnost zobrazit si tržbu internetového obchodu prostým zaznačením přijatých objednávek, o jejich seřazení dle výše objednávky, o jednoduchém zjištění si průměrné spamovosti emailu kvůli nastavení spamfiltru, o tom, že nemusím uživatele nutit použít kvůli operaci suma, průměr další stomegový SW a o tom, že když paní X z oddělení Y chce statistiku toho či toho, tak ji prostě nechám do pošty přitékat pravidelné výkazy s metadaty a co si s tím ona udělá je mi již jedno. Hlavně mne nebude otravovat s tím, že krom denní chce ještě týdenní součty a měsíční průměry a já nevím co. Proč asi moderní správci souborů stále více manipulují s metadaty? Proč to nepřenechají skriptům? IMAP a další MS systémy pro mne nejsou ničím jiným než trochu jiný filesystém. Vnímám je jako datový sklad a budu rád pokud s těmi daty budeme umět i něco více než přečteno, nepřečteno. Vy si pro mne za mne používejte GMail a doufejte, že se statistickými operacemi nad metadaty nepřijde jako první Google Byl byste v argumentační nouzi.

[mrzout]

Mockrat jsem chtel videt nejakou hlavicku a kmail ji neumoznuje vybrat:

http://bugs.kde.org/show_bug.cgi?id=16270 (zahlasuj si)

Agregacni funkce by mohly byt zajimave, treba prave na ten soucet velikosti. Ale je to moc novatorske,<rejp>dokud s tim neprijde Microsoft Outlook</rejp>, tak se v kmailu nedockame

[mrzout]

sorry, tenhle bug je trosku o necem jinem, ta moje anglictina :)

[Fred]

Outlook uz to davno umi. Prinejmensim pet let. Jenze adminu co to umi rozbehnout je asi tak 10x mene nez linuxovych adminu a to kazdy breci jaky je tech nedostatek.

Samozrejme to neni udelane tak diletantsky, ze by to davalo nejaky bordel do nesifrovanych hlavicek.

[kavol]

hm, a nechtěl bys spíš zasponzorovat někoho, kdo prvně spraví padavost kmailu při použití IMAPu, a pak teprv uvažovat o advanced featurách? - k čemu je nová vlastnost, která kmail nad IMAPem spolehlivě shodí?

[moira]

Padavost? Pouzivam KMail s IMAP dennodenne a nevim, kdy mi naposled spadnul. Nebude problem s IMAPem na serverove strane (nestandardni implementace)? I kdyz je pravda, ze i to by mela dobra aplikace ustat, mozna s chybou ale urcite ne padnout.

[kavol]

Padavost?

ano

Pouzivam KMail s IMAP dennodenne a nevim, kdy mi naposled spadnul.

hmmm ...

Nebude problem s IMAPem na serverove strane (nestandardni implementace)? I kdyz je pravda, ze i to by mela dobra aplikace ustat, mozna s chybou ale urcite ne padnout.

odpovídáš si sám ... nehledě na to, že se to děje proti různým serverům

[petr]

A zatímco vy tady dva dny diskutujete, já takovou věc napsal v Perlu za 30min včetně "naučení se" všech perlích balíků k tomu potřebných

[Jiří (BoodOk) Kadeřávek]

To je dobrý, dá se někde vidět jak to s pošťákem běží dohromady?