Entrevista com Dmitry Yemanov (Firebird)

1) Qual é a sua ocupação oficial no momento?

Eu trabalho em uma empresa de consultoria onde lidero o departamento de R&D. Nós desenvolvemos soluções HR/CRM/ERP para nossos clientes. Temos 2 níveis de produtos – os destinados a grandes corporações que utilizam Oracle (que são bem mais caros), e os destinados à empresas menores baseados no Firebird (e obviamente mais baratos). O software cliente é desenvolvido em Delphi.

2) Como se deu o seu envolvimento com o projeto Firebird ?

Nossa empresa precisava de um RDBMS gratuito para um novo software que estávamos desenvolvendo. Começamos a utilizar o InterBase 6.0 assim que a Borland liberou seu código sob a licença IPL, e mudamos para o Firebird (FB) assim que ele surgiu.

Depois disso, comecei a pesquisar o código fonte do FB e acompanhar a lista de desenvolvedores (fb-devel). Foi muito interessante para mim, especialmente porque eu nunca tinha me envolvido em um projeto Open Source antes. Alguns meses depois já estava apto para trabalhar em algumas partes do código. Algum tempo depois eu submeti minhas primeiras correções para o time de desenvolvedores do Firebird e logo depois ganhei direito de upload na árvore CVS.

3) Qual é o seu papel atual no projeto?

Desenvolvedor central (basicamente da engine do banco e das rotinas de DSQL). Também sou o gerente de lançamento das versões em desenvolvimento (1.5 e 2.0), mantenedor da versão para Win32, e um dos administradores do projeto.

4) Qual parcela do seu tempo você dedica ao desenvolvimento do Firebird ?

Na média de 20 a 30 horas por semana. Depende basicamente das tarefas em que eu estou trabalhando em determinado momento. Gostaria de dedicar mais tempo ao projeto (especialmente no desenvolvimento da versão 2.0), mas infelizmente meu “emprego oficial” toma muito do meu tempo.

5) Quais foram as maiores dificuldades para se familiarizar com o código do InterBase 6.0 após sua abertura pela Borland ?

A base de código é bastante complexa. É difícil de aprendê-la, desenvolve-la e mantê-la. É por isso que hoje nós estamos fazendo uma grande limpeza e re-estruturação do código. Não existe praticamente nenhuma documentação sobre o código fonte disponível.

6) Quais foram os principais recursos que você adicionou ao Firebird (incluindo os que ainda não foram publicados oficialmente)?

Ordenação em memória, triggers universais, novas variáveis contextuais (connection_id, transaction_id, row_count, etc), índices únicos que aceitam NULLs, comando LEAVE para gerenciamento de loops, algumas melhorias no parser e toneladas de correções de bugs, que eu considero ser o trabalho mais importante. O release notes traz um lista completa de tudo que eu já fiz.

Para a versão 2.0 adicionei algumas novas funcionalidades: cursores explícitos em PSQL, expressões na função SUBSTRING e algumas outras funcionalidades que ainda estão em desenvolvimento como por exemplo eventos parametrizados (no qual eu comecei a trabalhar em 2001) e o novo protocolo local (chamado de XNET).

7) Como é feita a sincronização e a comunicação entre os desenvolvedores do FB no que diz respeito à atribuição de tarefas, resolução de conflitos de código, uploads, etc?

Todos são bem vindos para participar do projeto e fazer o que puderem e tiverem interesse em fazer. Temos muitos usuários que nos mandam suas necessidades e pedidos de novas funcionalidades que, por sua vez, ficam registradas no nosso tracker no SourceForge para futuro desenvolvimento. Acredito sermos bastante democráticos e podemos balancear entre os interesses dos próprios desenvolvedores, patrocinadores e usuários. As questões sobre o desenvolvimento são discutidas na lista fb-devel e em e-mails privados. A comunicação é feita através de fóruns, e-mails e ICQ. Os uploads são feitos pelos encarregados das versões e mantenedores de plataformas, que são designados especificamente para essa função.

Os raros conflitos de código são resolvidos automaticamente pelas ferramentas de CVS ou, quando isso não é possível, manualmente. O tamanho do código é sempre um fator complicador na hora de compatibilizar o desenvolvimento de todos.

8) Existem muitos desenvolvedores russos trabalhando no código do Firebird. Porque você acha que isso acontece? O Firebird é popular na Rússia?

Todos os softwares da Borland tinham algum tipo de suporte do governo para serem usados nas escolas e universidades. Como resultado, quase todos os programadores na Rússia tiveram contato com o Turbo Pascal e Turbo C/C++. Quando o Delphi/Cbuilder foram lançados eles se tomaram as ferramentas mais utilizadas no país para o desenvolvimento Win32. Como o InterBase acompanhava os produtos da Borland, acabou se tornando bastante popular. O Firebird não poderia ser ignorado nessa questão, já que ele tem basicamente os mesmos recursos (na verdade mais recursos do que o IB), mais bugs corrigidos e, é claro, porque ele é grátis.

Nós russos sempre gostamos de “fuçar” nos códigos internos dos softwares e resolver os problemas por conta própria, sem precisar do suporte do fabricante. Se precisarmos de algum recurso então é melhor termos acesso ao código e desenvolve-lo nós mesmos, ao invés de esperar a Borland (ou qualquer outro fabricante) entender as nossas necessidades e agendar suas implementações. Portanto, eu não estou surpreso ao ver vários russos no projeto.

9) Se você fosse re-escrever todo o código do banco, o que você mudaria ?

Algumas partes da base de código já foram re-escritas e esse processo continuará. Eu não posso apontar algum sub-sistema que será refeito do início, pois muito código tem que ser analisado e provavelmente redesenhado ou reimplementado. Jim [Starkey] (criador do InterBase) começou uma re-estruturação agressiva no código do FB 2.0 para o seu projeto Vulcan.

Existem várias idéias boas para a engine do banco e tudo que precisamos fazer é prover uma boa implementação para elas. Os problemas mais críticos, na minha humilde opinião são causados por estruturas de dados ineficazes e por alguns algoritmos usados nos sub-sistemas. Atualmente, com todo o poder de processamento e memória que temos disponíveis, alguns algoritmos antigos acabaram se tornando um grande gargalo de performance. Isso se torna um fator crucial quando o gargalo está relacionado a uma parte vital da engine, como por exemplo a coleta de lixo (garbage collection).

Nota: Jim Starkey foi contratado pela IBPhoenix para desenvolver uma versão do Firebird compatível com SMP, totalmente multithread e compatível com os novos processadores de 64bits. Para isso ele derivou o código do Firebird 2.0 e criou o Firebird Vulcan, também Open Source, que já está em fase de testes e terá muitas das suas novidades incorporadas ao Firebird tradicional.

10) Você acredita que o Firebird já tem força suficiente para confrontar os bancos de dados comerciais, como o Oracle ou o MSSQL? E sobre o PostgreSQL?

Sobre os grandes bancos comerciais, eu tendo a dizer “não”. Nós podemos competir em algumas áreas, mas isso pode ser considerado sorte nossa, ou então algum problema deles. Ainda há muito a ser feito para confrontar por exemplo o Oracle. Hoje podemos “brigar” sem problemas com o PostgreSQL e  tenho certeza que temos força suficiente para derrota-lo.

11) Ainda sobre o assunto Firebird x PostgreSQL, você poderia listar alguns prós e contras de cada um?

O Postgres implementou as mesmas coisas que já existem no InterBase há muito tempo. O MVCC do Postgres é praticamente um clone do mecanismo de versioning do InterBase. Se eu não estiver enganado, eles não tinham um mecanismo online de garbage collection até as versões mais recentes. Na minha opinião as extensões objeto-relacionais e tipos de dados geométricos são mais um exotismo do que uma necessidade real. Há também o problema de não haver uma versão nativa para Windows!

Eu não estou querendo dizer que o PostgreSQL é ruim. Eles têm alguns recursos interessantes que nós ainda não temos (ex: procura textual, índices com expressões e histogramas de estatísticas de dados). Se você contar projetos comerciais complexos desenvolvidos com IB/FB x PostgreSQL, eu acredito que o IB/FB saia na frente. Talvez o resultado da pesquisa recente do site LinuxQuestions.org mostre exatamente isso.  (http://www.linuxquestions.org/questions/showthread.php?s=&threadid=116360)

12) Você poderia nos dizer quais são alguns dos recursos planejados para o FB 1.6 e 2.0 ?

Os maiores objetivos são:

·         Nova ODS (On Disk Structure), com muitas melhorias na linguagem;

·         Suporte a SMP na versão SuperServer do servidor;

·         Monitoramento de conexões e queries no servidor;

·         Optimizador mais inteligente e novos caminhos de acesso a dados;

·         Acesso a índices mais rápidos e melhorias de performance.

Uma lista mais completa será publicada em breve no site oficial.

13) Como o Firebird é um banco de dados de código aberto, outros bancos de dados (comerciais ou não) baseados no IB 6.0 (como o próprio IB 7.x) podem incorporar códigos do Firebird em seus projetos e se beneficiar com isso. Como você se sente a esse respeito?

Quanto mais nós alterarmos o código, mais difícil será de algum outro fabricante incorporar nosso código e nossas idéias em seus produtos. Mas isso pode realmente acontecer. Eu não gosto da idéia, mas tenho que conviver com ela.

14) O servidor embedded implementado por você é uma ótima novidade. Foi difícil implementá-lo? Como surgiu a idéia de criá-lo?

Na verdade foi muito fácil. A arquitetura OSRI (Open Systems Relational Interface) do servidor declara cada sub-sistema de maneira que tenha a mesma interface pública. Isso significa que a engine do banco implementa a mesma API, que estava escondida dentro dos binários e era chamada apenas pelo servidor remoto como parte do processo de comunicação cliente-servidor. O que eu fiz foi remover o sub-sistema remoto e tornar os pontos de entrada da engine públicos, dando origem assim ao servidor embedded. Na verdade a coisa é um pouco mais complicada já que o servidor embedded é também um gateway para os servidores remotos, mas já dá pra ter uma idéia.

Essa idéia foi inicialmente mencionada no livro "InterBase World" (publicado na Rússia) e era um recurso que seria implementado no Yaffil (ver Nota 1). A idéia era discutida nos newsgroups russos continuamente. Quando os desenvolvedores do Yaffil a implementaram, eu segui mais ou menos os mesmos passos e implementei algo similar. O servidor embedded do Yaffil era baseado na versão ClassicServer pois essa versão tornava mais fácil sua implementação (a versão Classic para Linux sempre teve uma embedded engine como parte da distribuição, pois não era possível conectá-lo de outro modo), mas algum tempo depois eles concordaram com a minha solução e implementaram o Yaffil embedded baseado na versão SuperServer (a versão do FB embedded sempre teve a arquitetura SuperServer, desde o início).

Nota 1

O Yaffil é um SGDB derivado do código do Firebird e que era desenvolvido na Rússia e distribuído através de uma licença comercial. Há alguns meses foi anunciada a junção do código do Yafill no Firebird 2.0, aproveitando todas as implementações feitas no Yaffil e que ainda não estavam disponíveis no Firebird.

15) O que você espera para o futuro do Firebird ?

Muito sucesso, é claro! Eu considero o Firebird o único banco de dados Open Source com recursos completos, estabilidade e rapidez para competir com alguns servidores comerciais em áreas genéricas de negócios. Há questões sérias que precisam ser resolvidas no desenvolvimento futuro, mas estamos cada vez mais próximos disso.

16) Como você vê o futuro dos bancos de dados comerciais?

O mercado para alguns deles continuará crescendo. Exceto pelo preço, os “grandões” são muito bons e fazem seu trabalho muito bem. Eu acredito que haverá mais integração entre os fabricantes. Os maiores tendem a incluir recursos de servidores de aplicação em seus produtos, forçando os usuários a usar uma lógica de negócio centrada em bancos de dados (compare os recursos do MS Yukon com os pacotes PL/SQL do Oracle's e a implementação Java e você terá uma idéia).

17) O que você pode dizer sobre o futuro do Firebird na questão de compatibilidade com a BDE, dbExpress e a BDP?

No futuro próximo, o Firebird manterá o máximo possível de compatibilidade com as tecnologias de acesso da Borland. Mas as pessoas deveriam começar a pensar no Firebird como um produto completamente diferente, que não necessariamente terá garantia de compatibilidade com as tecnologias de acesso nativas da Borland. Mas eu não considero essa questão crucial, pois nós temos um grande número de drivers, bibliotecas e providers de terceiros que suportam o Firebird muito bem, e que podem ser utilizados nas ferramentas da Borland.

18) Você tem algo a dizer para os usuários do FB no Brasil.

Continuem usando e dando suporte ao FB. Mantenham sua excelente comunidade forte e bem informada. Eu espero no futuro ver desenvolvedores brasileiros fazendo parte do projeto!