Что они курят известно — листинги регистра, убойная вещь скажу я вам…. :-) [ >>> ]

Кстати, так оно и есть. Я понемногу ковыряю регистровский движок, внедряя удобный для себя подход к контент-модели… 10% кода ушло в /dev/null, 20% полностью переписано. Так что я могу много чего рассказать о регистровских потрохах. Но не буду, ибо нефик!

Еще 10 000 строк на php — и золотой ключик от Регистра у нас в кармане…

1. Версия тестовая, поэтому ставить лучше всего на тестовую копию. Претензии по поводу угробленных Регистров не принимаются.
2. Это не установочный с нуля версия, а upgrade с R1.4
3. От php требуется поддержка DBA (хотя никто не запрещает использовать обычные файлы. После небольшой модификации abstraction level, разумеется)

Чего нет?
Нет статистики и постинга в LJ. Поскольку мне они были не нужны. Еще нет поддержки клиента. Руки не дошли.

Чего добавилось?
- memories: внутренние, внешние, френдовые
- nodes, threads [ >>> ]
- уникальные id записей и комментариев
- трехуровневая структура хранения записей
- поддержка схемы lynx
- список записей за месяц (без разбивки по датам)

Скрипты будут несколько позже.

1. Конвертация

Конвертируются:
- записи (только те, которые присутствуют в daylist.txt)
- комментарии
- мемориз (только расширенного формата)
- френд-лента

Для конвертации необходимо дать права на запись на каталог dbx и откорректировать тип DBA в скриптах. Скрипты исполняются 1 раз и удаляются.

2. Скрипты (регистровские)

Ставятся поверх существующих.
В lib/lib.inc.php в d_ropen() и d_wropen() откорректировать тип DBA. Дать права на запись на каталог ximp

Известные косяки
- после редактирования записи скрипт не показывает актуальное содержание записи
- нет проверки уникальности subj при добавлении новой записи и формировании адреса. Поэтому «test1» и «test2» будут одной удвоенной записью.

Скрипты: для конвертации, регистровские

[-1]

Ну ее нафик, эту логичность. Будем делать так, как практичнее.

Вместо стильного календаря (и из-за особенностей трехуровневой аритектуры) прикрутил возможность работать с архивом списком и по месяцам. Впрочем и «все скопом» тоже работает. Надо бы и во френд-ленте так сделать.

Я вот о чем думаю: нужно ли сюда прикручивать atom feed? Вроде как вполне rss хватает, а плодить «лишние» сущности как-то лень…

Хотя некоторые считают ключевые слова чуть ли не панацеей, я в этого джинна не верю.
Да, ключевые слова позволяют разложить одну большую кучу записей на несколько мелких кучек — согласно тематике. Но от этого куча так и остается неупорядоченной.
Упорядочить записи можно. Если предварительно сгенерировать список ключевых слов по принципу УДК (не копировать!). И при этом много ключевых слов останутся незадействованными.
Поэтому обычно ключевые клова вводятся по мере надобности. А с предыдущими записями, которые подходят под это ключевое слово — что делать? Ворошить и перебивать КС в N записей? Так лень же!
Фасетная классификация? ФК начинает хорошо работать на большом объеме равномерно раскиданных данных. 10 000, например. А когда записей пара сотен, издержки на ФК превышают эффективность использования.
Сотовая классификация, тоже в жопе, поскольку у меня нет плотной упаковки записей.
Что же делать? Есть два пути, облегчающих жизнь:
а) использовать ортогональную систему классификаторов (иерархическая/многоуровненвая рубрикация, threads, маркеры важности), позволяющие искать по стыкам (точкам пересечения, converge)
б) использовать параллельную систему — аннотации по контексту (constrict, предельно сжатое содержания записи). Минус: не умею я грамотно сжимать контекст и поддерживать релевантность аннотаций во времени.

Раздумывая о вечном классификации контента всегда натыкаешься на две трудности:
1) Сама по себе КК на пустом месте не возникает — ее нужно прописывать руками в каждую запись. Каждый раз, как только мы вводим/изменяем систему КК. Выходом была бы динамическая КК, но до этого жить и жить
2) КК необходимо составлять до, а не после появления записей. Соотвественно, требуется предугадывать содержание будущих записей и их место в КК (мелкая корректировка под сиюминутные нужды на это не влияет).
Если бы не две этих жопы, жить было бы легче и веселей.

Чтобы не было дурацких вопросов, немного поясню.

Вот эти маленькие -1 и +1 — это навигационные элементы, позволяющие «листать» записи за этот же день (т.е. «предыдущий» и «следующий»).

Идея анализа внешних поисковых запросов, хотя и заманчива, но с практической стороны — близка к бесполезной, поскольку:
- непонятно, что именно ищет посетитель
- посетитель может искать вполне конкретную запись, и не согласен на принудительную замену
- непонятно, какую из N записей context chain считать более релевантной перехваченному запросу.

Как вариант, после анализа внешних поисковых запросов можно выводить не конкретную запись, а context chain. Но польза от этого сомнительна, а усилий требует.

И что делать? А ничего. Тем, кто заходит в блог и пытается откомментировать запись годичной давности, уже ничего не поможет. Кроме белых тапок и горизонтального положения…
А для остальных будем строить context chain. Вот urbansheep предлагает строить цепочки вручную и по номерам. Ну а я записываю в todo «поддержка перекрестных threads» (т.е. когда запись входит в несколько нитей)