Estou nos estágios iniciais de escrever um modo principal do Emacs para a rede Stack Exchange ; se você usa o Emacs regularmente, isso irá beneficiar você no final.
Para minimizar o número de chamadas feitas para a API do Stack Exchange (limitado a 10000 por IP por dia) e ser apenas um cidadão geralmente responsável, desejo armazenar em cache as informações que recebo da rede e armazená-las na memória, aguardando ser acessado novamente. Estou realmente preso quanto à estrutura de dados para armazenar essas informações.
Obviamente, será uma lista. No entanto, como em qualquer estrutura de dados, a escolha deve ser determinada por quais dados estão sendo armazenados e como serão acessados. Gostaria de poder armazenar todas essas informações em um único símbolo, como stack-api/cache. Portanto, sem mais delongas, stack-api/cachehá uma lista de consentimentos codificados pela última atualização:
`(<csite> <csite> <csite>)
onde <csite>estaria
(1362501715 . <site>)
Neste ponto, tudo o que fizemos foi definir uma lista de associação simples . É claro que devemos ir mais fundo .
Cada <site>um é uma lista do parâmetro da API (exclusivo) seguido de uma lista de perguntas:
`("codereview" <cquestion> <cquestion> <cquestion>)
<cquestion>Você adivinhou que cada uma é um contras de perguntas com a última atualização:
`(1362501715 <question>) (1362501720 . <question>)
<question>é um contras de uma questionestrutura e uma lista de respostas (novamente, concordadas com o último horário de atualização):
`(<question-structure> <canswer> <canswer> <canswer>
e `
`(1362501715 . <answer-structure>)
Esta estrutura de dados é provável mais precisamente descrita como uma árvore, mas eu não sei se há uma maneira melhor de fazer isso considerando a linguagem, Emacs Lisp (que não é tão diferente do Lisp que você sabe e amor em tudo ) . Os consentimentos explícitos são provavelmente desnecessários, mas ajudam meu cérebro a envolvê-lo melhor. Tenho certeza de que <csite>, por exemplo, apenas se tornaria
(<epoch-time> <api-param> <cquestion> <cquestion> ...)
Preocupações:
- O armazenamento de dados em uma estrutura potencialmente grande como essa tem alguma compensação pelo desempenho do sistema? Gostaria de evitar o armazenamento de dados estranhos, mas fiz o que pude e não acho que o conjunto de dados seja tão grande em primeiro lugar (para uso normal), pois é apenas texto legível por humanos em proporção razoável. (Estou planejando selecionar dados antigos usando os horários no início da lista; cada um herda sua última hora de atualização de seus filhos e assim por diante na árvore. Até que ponto esse abate deve ocorrer: eu não estou certo.)
- O armazenamento de dados como esse tem algum problema de desempenho para o que deve ser usado? Ou seja, as operações de configuração e recuperação sofrerão com o tamanho da lista?
Você tem outras sugestões sobre como seria uma estrutura melhor?
org); inserir <!-- language: blah>onde necessário (dependendo do modo em que a edição do código foi realizada); coisas assim. Veja o README no GitHub para mais informações, e se sentir mais bem-vindo para sugerir recursos. Quanto mais eu souber sobre isso antes, melhor ele poderá ser projetado. editar para não mencionar emacs atalhos de teclado;)