Para esse trabalho, o objetivo é desenvolver um pequeno sistema no qual seja possível realizar operações relacionadas a manuscritos que ainda necessitem de revisão. I.e., deve haver a opção de autores poderem enviar seus manuscritos para revisão e de revisores poderem listar e avaliar os manuscritos a espera de revisão.
Estratégia
Na versão atual do DPublish, existe o contrato DPublish, que serve como um repositório de manuscritos, ligando o ID de um manuscrito ao endereço de seu autor. Dessa forma, conseguímos ter uma forma geral de acessar os manuscritos já publicados.
No entanto, é necessário saber quais manuscritos ainda não receberam uma revisão. Para isso, a partir de um contrato que irá implementar o sistema de revisão, podemos consultar quais manuscritos já receberam revisão ou que tiverem revisões avaliadas como válida.
De qualquer forma, é importante que possamos acessar esse conjunto de dados de uma maneira performática. Dado isso, podemos considerar duas estratégias diferentes:
Para cada nova chamada ou mudança no contrato DPublish, guardar em um novo contrato o ID dos novos manuscritos, ao mesmo tempo que associa a eles a informação de que ainda não foram revisados. Além disso, também devemos ouvir o contrato que vai implementar a revisão dos manuscritos, verificando se a regra que avalia se um manuscrito ainda espera revisão foi satisfeita para algum dos que ainda não possuem revisão, e modificar seu valor.
No próprio DPublish, associamos a cada ID de uma publicação uma estrutura de dados que vai conter o endereço do publicador e seu status de revisão. Ou seja, modificamos o mapping que existe atualmente para que possa guardar mais dados. Além disso, o contrato que irá implementar revisão deve modificar a variável que indica se o manuscrito está revisado diretamente no contrato DPublish.
Essas duas estratégias possuem suas vantagens e desvantagens. Uma vantagem da primeira estratégia é sua implementação quase indolor, sem precisar modificar diretamente outros contratos. A vantagem da segunda estratégia é ter um menor uso de recursos no geral, pois não duplicamos o ID dos manuscritos ou realizamos manipulações muito elaboradas.
Uma vez que alguma das estratégias for implementada, temos que a opção de publicar um manuscrito para revisão é feita de forma automática, assim que um pre-print é disponibilizado.
Porém, ainda seria necessário uma interface mais amigável para a consulta dos manuscritos, que pode ser feito em Python e disponibilizado via uma REST API ou diretamente em uma interface web para uso final pelos autores e revisores.
Requisitos
O requisito central desse trabalho é a criação de um contrato de revisão. Sua implementação e interface vão ter bastante influência em como o sistema de manuscritos esperando revisão vai ser feito.
Em quesito de viabilidade, temos situações diferentes para cada uma das estratégias. A primeira necessita que o Solidity ofereça a possibilidade de trabalhar com eventos e observadores na escala proposta. Já a segunda requer que haja um esforço coordenado na criação de um bom design dos contratos a serem usados nesse trabalho a fim de garantir que as regras de negócio sejam bem implementadas em cada um deles.
Cronograma
A priori, o cronograma da realização desse trabalho se baseia no tempo de desenvolvimento dos outros contratos (modificações no DPublish, criação do contrato de revisão, etc.). Mas, uma vez isso resolvido, os seguintes passos serão seguidos:
Estudo e planejamento da implementação da estratégia escolhida.
Implementação, desenvolvimento e modificação dos contratos para atender as especificações.
Plano de trabalho
Tema: pool de manuscritos esperando revisão.
Objetivo
Para esse trabalho, o objetivo é desenvolver um pequeno sistema no qual seja possível realizar operações relacionadas a manuscritos que ainda necessitem de revisão. I.e., deve haver a opção de autores poderem enviar seus manuscritos para revisão e de revisores poderem listar e avaliar os manuscritos a espera de revisão.
Estratégia
Na versão atual do DPublish, existe o contrato DPublish, que serve como um repositório de manuscritos, ligando o ID de um manuscrito ao endereço de seu autor. Dessa forma, conseguímos ter uma forma geral de acessar os manuscritos já publicados.
No entanto, é necessário saber quais manuscritos ainda não receberam uma revisão. Para isso, a partir de um contrato que irá implementar o sistema de revisão, podemos consultar quais manuscritos já receberam revisão ou que tiverem revisões avaliadas como válida.
De qualquer forma, é importante que possamos acessar esse conjunto de dados de uma maneira performática. Dado isso, podemos considerar duas estratégias diferentes:
Essas duas estratégias possuem suas vantagens e desvantagens. Uma vantagem da primeira estratégia é sua implementação quase indolor, sem precisar modificar diretamente outros contratos. A vantagem da segunda estratégia é ter um menor uso de recursos no geral, pois não duplicamos o ID dos manuscritos ou realizamos manipulações muito elaboradas.
Uma vez que alguma das estratégias for implementada, temos que a opção de publicar um manuscrito para revisão é feita de forma automática, assim que um pre-print é disponibilizado.
Porém, ainda seria necessário uma interface mais amigável para a consulta dos manuscritos, que pode ser feito em Python e disponibilizado via uma REST API ou diretamente em uma interface web para uso final pelos autores e revisores.
Requisitos
O requisito central desse trabalho é a criação de um contrato de revisão. Sua implementação e interface vão ter bastante influência em como o sistema de manuscritos esperando revisão vai ser feito.
Em quesito de viabilidade, temos situações diferentes para cada uma das estratégias. A primeira necessita que o Solidity ofereça a possibilidade de trabalhar com eventos e observadores na escala proposta. Já a segunda requer que haja um esforço coordenado na criação de um bom design dos contratos a serem usados nesse trabalho a fim de garantir que as regras de negócio sejam bem implementadas em cada um deles.
Cronograma
A priori, o cronograma da realização desse trabalho se baseia no tempo de desenvolvimento dos outros contratos (modificações no DPublish, criação do contrato de revisão, etc.). Mas, uma vez isso resolvido, os seguintes passos serão seguidos: