[SP-pm] Try::Tiny : uma opção de exception, mas nem tanto !!!

[Lucas Moraes]

Mantovani, mas resposta pode ter só um destinatário ou vários, isso depende
da pergunta. :)

Em 21 de junho de 2012 17:50, Solli Honorio <shonorio em gmail.com> escreveu:

> É que referenciando deste maneira fica mais acadêmico :D !!!
>
> Solli Honorio
>
> Em 21 de junho de 2012 17:47, Stanislaw Pusep <creaktive em gmail.com>escreveu:
>
> Eden, concordo com os seus argumentos sobre mandar plaintext.
>> Não entendi uma parte: estou usando webmail do Gmail, no Chrome, o que
>> deveria ter gerado um multipart coerente parseável pelo seu cliente de
>> email. Ou a sua observação sobre contenttype se refere a outra coisa? Mas
>> isso é o de menos...
>> Voltando à questão do cargo cult: muitas pessoas (eu inclusive)
>> simplesmente colam URL no meio do texto, sem o "fru-fru" de colocar número
>> da referência entre colchetes. Qualquer cliente de email que se preza
>> identifica URL e coloca um style/ação adequados.
>> Atrapalha a leitura? Não deveria, IMHO.
>>
>> ABS()
>>
>>
>>
>>
>> 2012/6/21 Eden Cardim <edencardim em gmail.com>
>>
>>> >>>>> "Stanislaw" == Stanislaw Pusep <creaktive em gmail.com> writes:
>>>
>>>     Stanislaw> Não é provocação :P Eu amo Vim, apesar de considerar ele
>>>    Stanislaw> altamente arcaico. Por essa ótica, o próprio email é
>>>    Stanislaw> arcaico. Mas arcaico != ultrapassado.  É que, para mim,
>>>    Stanislaw> uso de [\d] para citação, no lugar de link, é um claro
>>>    Stanislaw> exemplo de um cargo cult.  Eden acabou de demonstrar que
>>>    Stanislaw> o Gmail não respeita muito os padrões de MIME/multipart
>>>    Stanislaw> adotadas pelo cliente de email dele. Para ELE, faz todo o
>>>    Stanislaw> sentido usar [\d] para citação. Mas para quem usa
>>>    Stanislaw> Gmail/Mail.app/Outlook (cruz-credo), é cargo cult.
>>>
>>> Bom, não sei o que pode ser, além de provocação, o padrão de envio de
>>> email não é definido pelo meu cliente e sim pela IETF (no RFC 2821,
>>> creio eu). Eu só acho mais conveniente, universal e rápido escrever um
>>> email em text/plain (e o gmail, que seta esses cabeçalhos por padrão,
>>> parece concordar comigo, rs), sem ter que ficar verificando detalhes de
>>> sintaxe/semântica, e é mais rápido copiar e colar um link direto do
>>> browser no texto. Também faz pouco sentido mandar emails cheio de
>>> fru-fru/florzinha prum grupo de discussão técnica onde pode ter código
>>> copiável/colável e nesse caso, o HTML atrapalha mais do que ajuda. Não
>>> tenho nada contra clientes que saibam parsear ou compor emails com HTML,
>>> inclusive, o cliente que eu uso tem essa capacidade. Enfim, a única
>>> coisa que eu cobro de um cliente de email razoável é que ele respeite os
>>> padrões tecnológicos vigentes, afinal de contas, a SPPM tá envolvida,
>>> querendo ou não, com o uso rígido de padrões, com toda a questão dos
>>> dados abertos e respeito aos padrões de consumo de dados por máquinas
>>> (não por humanos, que querem fru-fru), que me parece ser uma filosofia
>>> bem contrária ao que você tá insinuando.
>>>
>>> --
>>> Eden Cardim
>>> +55 11 9644 8225
>>> =begin disclaimer
>>>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>> =end disclaimer
>>>
>>
>>
>> =begin disclaimer
>>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>> =end disclaimer
>>
>>
>
>
> --
> "o animal satisfeito dorme". - Guimarães Rosa
>
> =begin disclaimer
>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20120621/0f49b5a0/attachment.html>