[GUFSC] Artigo: "Type Managers"

[Leonardo Trentini Lang]

> > Em música temos o Rhythmbox, que pode ser descrito como um primo
> > pobre GTK do amaroK.. =)
>
> Já tinha ouvido falado destes dois, mas nunca olhado de perto...
> Parecem interessantes, mas ainda estão muito aquém do que eu teria
> em mente para uma aplicação deste tipo ;)

Concordo. Mas a responsabilidade não é só da aplicação.

> [...]
> > Eu, particularmente, concordo com quem tachou o texto de
> > forçado, fazendo nótica demais com muito pouco de novo.
>
> Eu recebi o ponteiro em uma outra lista da qual participo. O
> artigo não teve muita aceitação nesta lista também, mas o mais
> interessante é que o ponteiro foi postado por um _usuário_ que
> achou o artigo interessante, enquanto o artigo foi refutado por
> _desenvolvedores_ que estavam naquela lista.

Talvez muitos desenvolvedores desconheçam a idéia sim, mas acho que
o problema principal é que, para aqueles que já conhecem-na, isso
realmente não é nada de novo.

Outro ponto importante é que o artigo traz idéias muito primitivas
sobre "o novo" gerenciamento de arquivos; mais à frente comento
algumas coisas além dessa visão que se restringe ao aplicativo em si.

> [...] Às vezes parece que grande quantidade dos software são escritos
> por programadores e para programadores, [...] A título de exemplo,
> eu tenho contribuído como tradutor de um projeto de SL, e dias atrás
> eu me achei traduzindo a seguinte mensagem (de um programa gráfico!):
>
> "Cannot open pipe to process"
>
> Achei isto fantástico. Não que eu (e que talvez a maioria nesta lista)
> não entenda a frase ou mesmo que ela seja difícil de traduzir para
> português, mas é porque ela simplesmente _não_ faz sentido para um
> usuário leigo.
> [...]

Voce acertou na mosca: esse é o ponto onde vejo grandes falhas de
projeto, nos aplicativos para Linux [e similares]. Muitos deles não
tem um design muito bem feito para tratamento de erros, e aí temos
problemas na hora de converter mensagens de sistema [de bem baixo
nível] em mensagens erro realmente significativas. Algo já se
tentou fazer, como padronizar valores de retorno de processos - em
algum(ns) BSD(s), não me lembro qual(is) - ou criar uma camada
que consiga transportar, além do texto plano, alguma semântica
associada - algumas bibliotecas, estilo glib, implementam esta
técnica. Mas há muita resistência para isso, infelizmente.

Particularmente, acho que a API POSIX dificulta esse tipo de
recurso. Não necessariamente impossibilita, mas desmotiva as
tentativas, basicamente por deixar em aberto a questão e limitar
os meios para se resolvê-la.

> Voltando a questão a questão do Amarok e do Rhythmbox, estes dois
> exemplos, aliados aos conceitos expressos no artigo, me fizeram pensar
> no processo de "gerenciamento de conteúdo musical". Imaginem o
> seguinte cenário:
>
> o você abaixa músicas da internet utilizando um cliente "peer-to-peer"
>   qualquer que lhe permita procurar as músicas que você deseja.
[...]
>
> Apesar de que para muitos de nós a separação de cada uma destas etapas
> é completamente evidente e até mesmo aceita como necessária, isto não
> vale para a grande maioria dos usuários que simplesmente querem tocar
> música ou ainda gravar uma música muito legal que ouviram na rádio em
> seu MP3 player.

Agora chegamos ao ponto principal da discussão: esse problema já tem
algumas soluções, mas em uma camada abaixo; o sistema de arquivos. Os
exemplos conhecidos - WinFS, Spotlight, e [futuramente] ReiserFS -
tentam(rão) eliminar o conceito de classificação em diretórios, trazendo
o conceito de classificação com algo semelhante a "tags" ou atributos de
arquivo, mais ou menos como funciona no Gmail e alguns gerenciadores de
bookmarks alternativos [para citar alguns casos]. Estes SAs transformam
o próprio sistema de arquivos em algo próximo a uma base de dados
[alguns até indo mais longe e implementando o modelo ACID], ajudando a
classificar a informacao de uma maneira mais flexível.

Faz algum tempo, foi desenvolvida uma solucao para o GNOME VFS que
usava uma base PostgreSQL como backend, e implementava este modelo
de sistema de arquivos. Mas não é preciso usar uma bazuca para matar
uma mosca [ou seja, usar uma base relacional SQL deste porte]:
algumas estruturas de dados pequenas com alguns algoritmos simples,
implementados como um plugin para o FUSE [por exemplo], já
serviriam como uma boa base.

O problema maior, entretanto, é outro: compatibilidade. Seria muito
difícil ter um recurso deste sem quebrar a compatibilidade com o
POSIX. E não quebrar a compatibilidade significaria subutilizar os
recursos, implementar gambiarras, ou até impor restrições um tanto
restritivas demais.

> [...] Apesar de todo este cuidado, isto _não_ significa que o
> paradigma proposto e estabelecido pela Microsoft através do Windows
> seja o melhor, mais eficiente, mais fácil ou ainda pior: definitivo.

Parece que até a Microsoft reconhece isso. Talvez temendo uma perda
de usuários, ou pelo fato de não ter uma solução técnica adequada
[ouvi Hans Reiser fazendo algumas críticas severas ao mérito técnico
do WinFS], adiaram o lançamento deste para depois do Longhorn.

> Em SL a liberdade para "tentar" novas idéias neste campo é muito
> maior, e se aliarmos boas idéias e esforço, podemos conquistar
> ainda mais usuários.

O problema é encontrar esse tal esforço.

[respondendo o outro e-mail]
> A questão é que essas mensagens ajudam quem está desenvolvendo. [...]
> Acho que para o desenvolvedor é muitíssimo mais fácil concertar algo
> cujo erro é nesse sentido do que ter usuários dizendo "Está aparecendo
> *Esse programa executou uma operação ilegal e será fechado*" :D

A idéia é exatamente o contrário do que você está pensando: incrementar
as mensagens de erro com informação, não decrementar. No FISL passado,
um funcionário da Sun palestrou sobre os "novos sistemas de detecção e
comunicação de erros inteligentes", que são basicamente implementações
sãs de comunicação de erros kernel<->userspace, com sistemas especialistas
para reconhecer a combinação e a freqüência dos erros, mostrando mensagens
*muito* detalhadas, e dando até sugestões para solucionar os problemas.
Isso sim é uma camada de tratamento de erros eficiente.

Entretanto, essa técnica pode ser utilizada não apenas para erros tão
baixo nível como os do kernel, mas para erros de aplicativos também.
Voltando ao ponto anterior: o problema principal é a dificuldade imposta
pela POSIX; por exemplo, esta limita muito a quantidade de informação
que um processo pode retornar para o sistema, o que dificulta uma
comunicação eficiente de erros entre processo pai/filho. É basicamente
uma questão de design e implementação, mas com o agravante da
compatibilidade - que, neste caso, atrapalha bastante a inovação.

E é isso.

PS: Agora eu que vou me desculpar pelo e-mail grande. :-)

-- 
Leonardo Lang AKA tlang em inf
-- 
Ciências da Computação (cco021)
Universidade Federal de Santa Catarina
-- 
BNU-FNS, SC, Brasil
-- 
Usuário GNU/(Linux #217916)