Я на початкових етапах написання основного режиму Emacs для мережі Stack Exchange ; якщо ви користуєтесь Emacs регулярно, це врешті принесе вам користь.
Для того, щоб мінімізувати кількість дзвінків до API Stack Exchange (обмежено 10000 за IP в день) і просто бути відповідальним громадянином, я хочу кешувати інформацію, яку я отримую з мережі, і зберігати її в пам'яті, чекаючи отримати доступ знову. Я дійсно застряг у тому, в якій структурі даних зберігати цю інформацію.
Очевидно, це буде список. Однак, як і у будь-якій структурі даних, вибір повинен визначатись тим, які дані зберігаються та яким чином вони будуть доступні. Що, я хотів би мати можливість зберігати всю цю інформацію в одному символі, наприклад stack-api/cache. Отже, без подальшої приналежності, stack-api/cacheце список консесів, введених останнім оновленням:
`(<csite> <csite> <csite>)
де <csite>було б
(1362501715 . <site>)
На даний момент все, що ми зробили, - це визначити простий список асоціацій . Звичайно, ми повинні заглибитись .
Кожен <site>- це список параметрів API (унікальний), а потім запитання зі списком:
`("codereview" <cquestion> <cquestion> <cquestion>)
Кожен <cquestion>- це, ви здогадалися, недоліки питань із останнім часом оновлення:
`(1362501715 <question>) (1362501720 . <question>)
<question>є мінуси questionструктури і список відповідей (знову - таки, consed з їх останнього часу поновлення):
`(<question-structure> <canswer> <canswer> <canswer>
і `
`(1362501715 . <answer-structure>)
Ця структура даних, ймовірно, найбільш точно описана як дерево, але я не знаю, чи є кращий спосіб зробити це, враховуючи мову, Emacs Lisp (яка не все так відрізняється від Lisp, якого ви знаєте і любите зовсім ) . Явні консистенції, ймовірно, непотрібні, але це допомагає моєму мозку краще обернутися навколо нього. Я впевнений, що <csite>, наприклад, просто перетвориться
(<epoch-time> <api-param> <cquestion> <cquestion> ...)
Побоювання:
- Чи зберігають дані в такій потенційно величезній структурі, як якісь компроміси щодо продуктивності системи? Я хотів би уникати зберігання сторонніх даних, але я зробив усе, що міг, і не думаю, що набір даних в першу чергу є таким великим (для звичайного використання), оскільки це всього лише текст, прочитаний людиною, в розумній пропорції. (Я планую вилучити старі дані, використовуючи час на чолі списку; кожен успадковує свій час останнього оновлення від своїх дітей і так далі вниз по дереву. Наскільки ця клітина повинна мати місце: я не впевнений.)
- Чи зберігають подібні дані якісь компроміси за ефективність за ті, які повинні використовувати їх? Тобто, чи встановлять і витягують операції страждають від розміру списку?
Чи є у вас інші пропозиції щодо того, як може виглядати краща структура?
org) вставлення, <!-- language: blah>де це необхідно (залежно від режиму, в якому було виконано редагування коду); такі речі. Дивіться README на GitHub для отримання додаткової інформації, і відчувати себе найбільш вітати запропонувати функції. Чим більше я знаю про це перед рукою, тим краще це можна розробити. редагувати, не кажучи вже про клавіатури Emacs;)