Limite de upload

daniel tygel dtygel at eita.org.br
Mon Sep 16 11:14:54 BRT 2013


Em 15-09-2013 09:09, Antonio Terceiro escreveu:
> On Sun, Sep 15, 2013 at 08:05:40AM -0600, daniel tygel wrote:
>> Oi Terceiro e demais,
>>
>> Overkill?
>>
>> Agora fiquei chateado.
> Tente não levar as coisas pro lado pessoal.
Não tem nada pelo lado pessoal aí. Não estou chateado com você. Estou 
chateado com o que identifico como um olhar diferente do time core para 
duas propostas provisória antes da infra-estrutura ser implementada.
>> Confesso. Havia proposto algo super simples,
>> não intrusivo, que cria uma ótima nova funcionalidade para o
>> noosfero que é a instalação de um plugin no tinymce e com isso
>> permite algo bastante funcional e útil para o usuário final (texto
>> colaborativo), enquanto não há estrutura no noosfero para que
>> plugins do tinymce sejam plugins do noosfero, e isso foi considerado
>> por vários colegas da Colivre como inaceitável.
> A sua implementação de plugin fazia com que o plugin do tinymce fosse
> carregado *incondicionalmente* pra todos os usuários, mesmo que não
> fosse usado.
A proposta não era de que o plugin do etherpadlite no tinymce fosse 
carregado incondicionalmente. Pelo contrário. Veja as mensagens que 
mandei a respeito, e verá que eu não queria, de maneira alguma, que isso 
fosse obrigatório. Até coloquei isso no comentário da configuração do 
etherpad no environment.rb.

O default proposto era o padUrl em branco, e isso deveria fazer com que 
o plugin não fosse carregado. Havia uma falha na minha proposta de 
código, pois pensei que o comportamento padrão (e escrevi isso nas 
mensagens a respeito) do tinymce era de que o plugin não carregava 
quando o padUrl era vazio (""). Fiz agora uma alteração no tinymce.rhtml 
que faz isso: não insere mais a palavra "etherpadlite" no "myplugins" se 
a variável padUrl está vazia, o que é o padrão no environment.rb. Por 
que isso não foi proposto aqui na lista como solução provisória até que 
a infra-estrutura de plugins fosse elaborada? Não: foi descartado "a 
priori".
>
> Por isso, e não por capricho, lhe foi dito que não dava pra aceitar como
> estava.  Consequentemente a solução seria suportar que plugins pudessem
> instalar plugins do tinymce de forma que o plugin tinymce só seja
> carregado caso o plugin do noosfero esteja ativado.
E eu disse que isso seria maravilhoso: que estava de acordo com uma das 
duas propostas: que o noosfero tivesse infra-estrutura de plugins do 
tinymce, ou que se criasse um plugin com um novo tipo de conteúdo 
(solução ainda melhor) com o nome "texto colaborativo". O que eu propus, 
haja visto que não teríamos condições de fazer nenhuma das duas 
alternativas agora, era fazer esta proposta de dar ao noosfero a 
capacidade de ter texto colaborativo como estava, sem carregar o plugin 
do tinymce incondicionalmente, e assim *já dava ao noosfero* a 
capacidade de ter esta funcionalidade, com pouquíssimo custo e alto 
benefício, até que fosse possível criar outra solução melhor. Ou seja, 
exatamente o que você propôs de fazer com a configuração de tamanho do 
upload de arquivos, que ainda por cima só é útil para o admin do 
ambiente, e será muito raramente usado (uma única vez, provavelmente). 
Aurium propôs em seu código (e você validou) que uma variável estranha e 
intrusiva chamada "multiplier", que nada mais é que o tipo "file_size" 
de "unidades", fosse criada ad hoc *enquanto não houvesse uma solução de 
infra-estrutura de unidades no noosfero*. Exatamente o que eu propunha 
para o plugin de etherpadlite para o tinymce do noosfero.
>
>> Agora, cria-se uma solução ad-hoc, dentro do core, de uma configuração
>> universal de unidades dentro de um arquivo específico que nem devia
>> ter configurações de padrões universais, e aí minha consideração de
>> que o noosfero antes prepare uma infra-estrutura de unidades é
>> considerada overkill por causa da simplicidade da proposta do upload?
>> A criação de uma variável universal de unidades é overkill, e mudar a
>> infra-estrutura do noosfero sobre plugins do tinymce não é overkill?
> O problema que a gente está resolvendo aqui é *especificamente*
> converter uma string pra um número de *bytes*.
>
> Esse código pode ser generalizado? Pode. Quando for o caso de
> implementar a solução universal pra conversão de unidades, a gente porta
> ele, não tem problema. Quando essa solução estiver pronta, pode me
> mandar um email que eu me comprometo a alterar o código em UploadFile,
> sem problemas.
A solução que enviei para o tinymce poderia ser generalizada, depois 
(seja via criação de infra-estrutura de plugins do tinymce para o 
noosfero, seja criando-se um plugin do noosfero de novo tipo de 
conteúdo). E eu me comprometo a fazê-lo quando tivermos condições 
(tempo) de fazê-lo. Mesmo assim, esta proposta de compromisso de 
melhoria posterior não foi feita por vocês. Eu propus de maneira 
explícita: que pensássemos no usuário final, já dando esta 
possibilidade, até que uma solução melhor do ponto de vista de código 
pudesse ser feita. Não vejo nenhuma razão desta possibilidade só se 
aplicar para a variável multiplier na configuração de tamanho de uploads.
>
> A solução proposta tem *zero* impacto no resto do sistema, e vai ser
> executada apenas 1 vez por cada processo que carregue o Noosfero sem
> qualquer impacto em usuários ou em servidores.
A solução que propus ao texto colaborativo tem o mesmo grau de impacto 
no resto do sistema, pois altera 3 linhas no environment.rb criando uma 
nova configuração (os outros códigos são no shared). A sua, do 
fileupload, cria a variável de definição de unidades (uma configuração) 
em um arquivo específico que não é de configurações básicas do sistema. 
Me parece ser o mesmo grau de impacto.
>
> Já o seu plugin tinymce, seria executada toda vez que alguém edita um
> artigo, e iria carregar 2 arquivos a mais (um arquivo .js e um
> arquivo.css), gerando 2 requisições a mais ao servidor em 100% dessas
> vezes, independente se o admin do site habilitou a funcionalidade ou
> não.
Como eu já disse, a proposta *não era* que o plugin fosse carregado 
quando a variável padUrl está vazia. Eu pensava que o tinymce não 
carregava o plugin quando esta variável era nula. Acabo de fazer este 
ajuste em 
https://github.com/dtygel/noosfero-ecosol/tree/etherpadlite-tinymce-embed .

Agora a proposta pode ser aceita provisoriamente, com o compromisso de 
futuramente fazer a infra-estrutura de plugins do tinymce no noosfero ou 
(melhor ainda) fazer um plugin com novo tipo de conteúdo 
'texto-colaborativo'? E se é aceito, por que não foi proposta esta 
alteração do código, como você propõe para as unidades?

>> Isso não são dois pesos e duas medidas?
> São situações diferentes (veja acima).
Sempre serão diferentes os casos. Mas vejo analogias importantes, 
conforme descrito acima. Os critérios é que me estão parecendo 
variáveis. Claro que posso estar (e e provavelmente estou) enganado.

Abraços,

daniel
>
> Um abraço,
>
>
>
> _______________________________________________
> Noosfero-br mailing list
> Noosfero-br at listas.softwarelivre.org
> http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/noosfero-br

-- 
(_.-~*´¨¯¨`*·~-.,-( •_•)-,.-~*´¨¯¨`*·~-._)
           .
     ,-. . |- ,-.          Educação,
     |-' | |  ,-|          Informação e
     `-' ' `' `-^          Tecnologia para
  http://eita.org.br       Autogestão

(_.-~*´¨¯¨`*·~-.,-( •_•)-,.-~*´¨¯¨`*·~-._)



More information about the Noosfero-br mailing list