Sono nelle prime fasi di scrittura di una modalità principale di Emacs per la rete Stack Exchange ; se usi regolarmente Emacs, questo alla fine ti sarà di beneficio.
Per ridurre al minimo il numero di chiamate effettuate all'API di Stack Exchange (limitato a 10000 per IP al giorno) e per essere solo un cittadino generalmente responsabile, voglio memorizzare nella cache le informazioni che ricevo dalla rete e memorizzarle in attesa di poter accedere nuovamente. Sono davvero bloccato su quale struttura dati memorizzare queste informazioni.
Ovviamente, sarà una lista. Tuttavia, come con qualsiasi struttura dati, la scelta deve essere determinata da quali dati vengono memorizzati e da come verranno acceduti. Cosa, vorrei poter memorizzare tutte queste informazioni in un unico simbolo come stack-api/cache . Quindi, senza ulteriori indugi, stack-api/cache è un elenco di consegne con chiave dell'ultimo aggiornamento:
'(<csite> <csite> <csite>)
dove <csite> sarebbe
(1362501715 . <site>)
A questo punto, tutto ciò che abbiamo fatto è definire una semplice lista di associazioni . Certo, dobbiamo andare più in profondità .
Ogni <site> è un elenco del parametro API (univoco) seguito da un elenco di domande:
'("codereview" <cquestion> <cquestion> <cquestion>)
Ogni <cquestion> è, hai indovinato, un cons di domande con il loro ultimo tempo di aggiornamento:
'(1362501715 <question>) (1362501720 . <question>)
<question> è uno svantaggio di una struttura question e un elenco di risposte (di nuovo, fornite con il loro tempo dell'ultimo aggiornamento):
'(<question-structure> <canswer> <canswer> <canswer>
e '
'(1362501715 . <answer-structure>)
Questa struttura dati è probabilmente descritta con la massima precisione come un albero, ma non so se c'è un modo migliore per farlo considerando il linguaggio, Emacs Lisp (che non è poi così diverso dal Lisp che conosci e ami affatto ). Le consegne esplicite sono probabilmente superflue, ma aiutano il mio cervello a completarlo meglio. Sono piuttosto sicuro che un <csite> , ad esempio, si trasformerebbe in
(<epoch-time> <api-param> <cquestion> <cquestion> ...)
Preoccupazioni:
- La memorizzazione di dati in una struttura potenzialmente enorme come questa ha qualche compromesso in termini di prestazioni per il sistema? Vorrei evitare di archiviare dati estranei, ma ho fatto quello che potevo e non penso che il set di dati sia così grande in primo luogo (per un uso normale) poiché è tutto un testo leggibile in maniera ragionevole. (sto pianificando di eliminare i vecchi dati usando i tempi in testa alla lista, ognuno eredita il tempo dell'ultimo aggiornamento dai suoi figli e così via lungo l'albero) In quale misura questo abbattimento dovrebbe avvenire: I non sono sicuro.)
- La memorizzazione di dati come questa ha dei compromessi in termini di prestazioni per ciò che deve usarli? Cioè, imposterà e recupererà le operazioni risentendo delle dimensioni dell'elenco?
Hai altri suggerimenti su come potrebbe essere una struttura migliore?