FAQ - Frequently Asked Questions...

  • Temos que utilizar maquina de estados? podemos usar diagramas de fluxos "flow charrts", ou diagramas UML de casos de uso?

O que se pretende é que vocês descrevam o vosso sistema, pelo que podem apresentar maquinas de estado ou diagramas de fluxo ou diagramas UML de casos de uso (ou mais do que um). O que preferirem para modelizarem a vossa solução. 

  • Numa primeira implementação do projecto, implementá-mos a comunicação com base na troca de objectos. Deveremos ter em conta a portabilidade?

O que está em causa não é a portabilidade mas sim a especificação do protocolo e a implementação do servidor de acordo com o protocolo.
O que devem realizar para o projecto é a especificação e implementação de um protocolo, e um protocolo define o formato das mensagens e a sequência de mensagens trocadas.
Quando vocês estão a realizar a comunicação com base na troca de objectos, fazem-no através da sua serialização, o quer dizer que vocês estão a definir campos de um objecto que serão traduzidos para bytes de uma maneira que desconhecem e não de uma maneira controlada segundo o formato de uma mensagem que vocês definiram e especificaram no protocolo.
Ao definirem o formato de uma mensagem tornam o cliente independente da plataforma do servidor, daí que o que eu disse de portabilidade foi como um exemplo. Tenham como exemplo o HTTP e o FTP.

  • Logo no ínico do texto do ponto 3 é dito que os utilizadores quando fazem o registo podem indicar tanto o nome DNS como o ip do Twitter. O que não percebemos é o que quer dizer com "fazer o registo", trata-se de criar uma conta?

Sim, é criar uma conta. Não é suposto criar uma conta cada vez que se quer ligar ao twitter. O que se quer dizer aqui é que devem poder aceder ao MicroTwitter tanto usando nome (e.g. MicroTwitter.pt) como o IP deste, em qualquer acesso. 

 

  • Para desenho da máquina de estados do servidor, não consigo pensar num caso em que seja preciso mais que um estado? 

Por exemplo, podem considerar existir o estado desligado, que quando se liga irá ver se interrompeu alguma acção (por exemplo, rebentou a meio da difusão de mensagens) e ficará à espera de mensagens.
Poderá haver outros. Não deverão apenas considerar os casos de sucesso, reúnam-se e comecem a "testar" teoricamente a vossa máquina de estados para todas as situações de insucesso que se lembrarem e depois vejam se passa na "bateria de testes". Falem com os vossos colegas.

 

  • Quando um utilizador cria um canal, fica automaticamente com previlegios de leitura e escrita?

 Sim, como é o criador tem automaticamente esses privilégios.

 

  • "Criar um canal, indicando o token para escrita ", "Aderir ao canal, indicando o token para escrita nesse canal". Qual o significado de "token para escrita"?

 O token para escrita pode ser uma cadeia de caracteres que o criador define, e que fica associado a esse canal. O utilizador que cria o canal tem que criar também a token para poder escrever no canal apresentando essa mesma token. 

Após isso um utilizador para aderir a um canal tem de ter conhecimento desse token, de maneira a impedir que qualquer pessoa se torne aderente mas sim apenas aqueles que conhecem uma palavra-chave definida pelo criador.

 

  • Quem pode apagar o canal? Apenas a pessoa que o criou?

Não. A funcionalidade apagar canal pode ser entendida como "desinscrever do canal", ou seja, qualquer pessoa que queira deixar de receber mensagens de um canal apaga-o da sua lista de canais, se for o ultimo aderente a fazê-lo então o canal é apagado definitivamente do lado do servidor (e podem optar por avisar os subscritores).

 

  • Quem é que pode enviar convites?

Os aderentes podem convidar outros utilizadores para serem aderentes (partilhando o token) ou subscritores. Podem considerar ou não (é opcional) que os subscritores podem convidar outros utilizadores para serem subscritores.

 

  • A adesão/subscrição a um canal só é possível com convite?

Para a adesão, qualquer pessoa pode aderir se conhecer o token. Mas em principio apenas quem conhece o token de um canal é o criador ou um aderente do canal que recebeu um convite.

Para a subscrição, é opcional e têm liberdade na vossa implementação.

Os convites permitem a um utilizador convidar os seus amigos, mesmo que estes não o conheçam.

 

  • É possível listar os utilizadores? Caso contrário, como é que um utilizador conhece outros utilizadores para enviar convites?

Do lado do cliente é possível listar subscritores e aderentes de um canal e não todos os utilizadores. Conhecem outros utilizadores da mesma maneira que tu adicionas um amigo teu numa qualquer rede social, convidas-o com o nickname dele se o conheceres.

 

  • Um dos serviços que se pede é poder listar todos os canais que o utilizador subscreveu, mas não será necessário listar também os que aderiu?

Já é uma opção vossa se quiserem listar os que ele aderiu (tem direitos r/w). Mas ele tem sempre direitos de r nos que adere, portanto qualquer aderente é automaticamente subscritor (o contrário não é verdade). O que é pedido no enunciado é a lista de todos os canais que o utilizador subscreve (ou seja, os que tem direitos de r e r/w).

 

  • Obtenção de listagem de mensagens curtas
    • Será obter as mensagens que o utilizador enviou ou recebeu?

As mensagens que recebeu (ou novas à espera de serem lidas). Se quiserem podem também opcionalmente listar as que ele enviou (ou todas as mensagens enviadas no site)    

          Será obter as mensagens que o utilizador enviou ou recebeu num canal?

Sugerimos obter todas, com identificação nelas do respectivo canal para onde foram enviadas. Também podem optar por canal se quiserem.

 

  • Quando se pede para manter um log no microTwitter das mensagens curtas, inclui as mensagens de controlo (TCP) ou é só as por UDP? A nossa confusão baseia-se no facto de este pedido estar descrito no ponto 3 referente às mensagens de controlo?

Só as por UDP.

 

  • A interface para disponibilizar as mensagens do log deve estar disponível no servidor ou em cada cliente?

Depende. Para listar as mensagens é no servidor, para receber em real-time uma nova mensagem é no cliente. 

 

  • Quando nos pedem para enviar mensagens curtas para canais, isto é, difundi-las pelos utilizadores desses canais, o que é suposto o microTwitter fazer?

Guardá-las e difundi-las logo a seguir 

Se for de facto para enviar para o microTwitter e este ficar encarregue de difundi-las pelos utilizadores, difunde-se apenas para aqueles online no momento, ou temos de fazer com que o microTwitter envie para todos os utilizadores da próxima vez que se conectem a este?

              Podem implementar de qualquer uma das duas maneiras referidas. 

Todas as mensagens curtas passam pelo microTwitter?

Sim.