Discussion:
FBR
(слишком старое сообщение для ответа)
Ruslan Demidow
2011-01-08 11:56:52 UTC
Permalink
Hello, All

После перехода на Windows 7 долго не запускал FBR. Сейчас наконец-то руки
дошли.
Тоссер мой пока не работает :-(
Но это поправимо.
После почти двух лет бездействия стало скучно.
Поэтому определил для себя (и FBR, естественно) новый путь развития: написать
FBR второй версии на VB.NET, основным способом хранения сообщений сделать базу
SQLlite (SQL и т.п. сделать потом будет не трудно). Тоссер встроить в FBR.
Таким образом будет связка типа "редакто+мейлер".
Старый сайт FIPS умер :-( Поэтому пока не будет более-менее нормально
работающего проекта - работа будет вестись локально.

Всех благ тебе, All.
ICQ 177792013 FmMB200016700 |||
*Hа уши давит* - тишина...
Mithgol the Webmaster
2011-01-12 11:45:36 UTC
Permalink
* изначально написано в эхоконференцию Ru.FIPS
* также было отослано в эхоконференцию Ru.FTN.Develop

Так было 14:56 08 Jan 11 написано от Ruslan Demidow к All:

RD> После перехода на Windows 7 долго не запускал FBR. Сейчас наконец-то
RD> руки дошли. Тоссер мой пока не работает :-( Но это поправимо. После
RD> почти двух лет бездействия стало скучно. Поэтому определил для себя
RD> (и FBR, естественно) новый путь развития: написать FBR второй версии
RD> на VB.NET, основным способом хранения сообщений сделать базу SQLlite
RD> (SQL и т. п. сделать потом будет не трудно). Тоссер встроить в FBR.
RD> Таким образом будет связка типа "редактор+мейлер". Старый сайт FIPS умер
RD> :-( Поэтому пока не будет более-менее нормально работающего проекта -
RD> работа будет вестись локально.

Чтобы тебе было поменьше работы, можешь ориентироваться на мой черновик
формата SQL-базы (именно для SQLite), придуманный одиннадцать месяцев назад:

╔═════════════════════════════════════════════════════────────────────────────
║ Цитата из эхи: Ru.FTN.Develop (Создание и поддержка фидонетовского софта)
║ URL сообщения: area://Ru.FTN.Develop?msgid=2:5063/88+4ce00091
║ Автор и время: Mithgol the Webmaster, 2:5063/88 (14 Nov 10 17:17)
║ Кому написано: All
║ Заглавие: Вехи развития фидошного SQL-тоссера. Веха 1: Fidosser + FGHI SQL
╚════════════════════════════════════════════════════════════════════─────────

Схему базы данных я по адресу area://Ru.FTN.Develop?msgid=2:5063/88+4b7e31cf
опубликовал ещё девятнадцатого февраля, когда надеялся предложить её принятие
какому-нибудь другому автору тоссера. Мне остаётся лишь повторить её, снабдив
русскими комментариями, и вновь упомянуть также её рабочее название (FGHI SQL):

-- Эхолист и модераторы.
--
-- Для каждой эхи, окромя обязательного эхотага, в базе может
-- храниться описание, адрес правил, теги выборочной подписки
-- (имитируемой выборочным показом сообщений, без нарушения
-- целостного распространения) и список модераторов с указанием
-- уровня авторитетности (0 у модератора, 1 у комодератора,
-- 2 у недокомодератора, и так далее). Пополнение этих сведений
-- производится посредством компиляции эхолиста (тривиальной)
-- и компиляции правил эхи (в настоящее время не автоматизируемо).

CREATE TABLE `echolist` IF NOT EXISTS (
`areaID` INTEGER PRIMARY KEY ASC AUTOINCREMENT,
`echotag` varchar(64) NOT NULL,
`description` text default NULL,
`domain` varchar(10) default `fidonet`,
`rules_URL` text default NULL,
`tag_filters` text default NULL
);

CREATE TABLE `moderators` IF NOT EXISTS (
`area` INTEGER REFERENCES echolist (areaID) ON DELETE CASCADE,
`address` varchar(23) NOT NULL,
`name` text default NULL,
`level` INTEGER default 0
);

-- Таблица заголовков и дат сообщений. Для вывода кратких одномерных списков
-- (как при настройке MsgListFast Yes в GoldED+) можно обойтись одной ею.

CREATE TABLE `messages` IF NOT EXISTS (
`id_msg` INTEGER PRIMARY KEY ASC AUTOINCREMENT,
`id_area` INTEGER REFERENCES echolist (areaID) ON DELETE CASCADE,
`fromname` varchar(35) default NULL,
`fromaddr` varchar(23) NOT NULL,
`toname` varchar(35) default NULL,
`toaddr` varchar(23) default NULL,
`subject` text default NULL,
`dateWritten` INTEGER default NULL,
`dateProcessed` INTEGER default NULL,
`parent_id_msg` INTEGER default NULL
);

-- Таблица флагов сообщений. Является на практике всего лишь расширением
-- заголовка, которое учитывается только при обработке почты тоссером.

CREATE TABLE `flagdata` IF NOT EXISTS (
`flagged` INTEGER REFERENCES messages (id_msg) ON DELETE CASCADE,
`killSent` INTEGER(1) default 0,
`private` INTEGER(1) default 0,
`direct` INTEGER(1) default 0,
`receipt` INTEGER(1) default 0,
`receiptReq` INTEGER(1) default 0,
`receipt` INTEGER(1) default 0,
`deleted` INTEGER(1) default 0,
`sent` INTEGER(1) default 0,
`locked` INTEGER(1) default 0
);

-- Таблица текстов сообщений. Тексты вынесены в отдельную таблицу, чтобы
-- не мешаться под ногами в тех задачах, которые текст не учитывают.

CREATE TABLE `messagetexts` IF NOT EXISTS (
`header` INTEGER REFERENCES messages (id_msg) ON DELETE CASCADE,
`message_text` text default NULL
);

-- Таблица кладжей сообщений. В некоторых задачах поиска кладжи сообщений
-- бывают нужны отдельно от текстов сообщений.

CREATE TABLE `kludgedata` IF NOT EXISTS (
`msg` INTEGER REFERENCES messages (id_msg) ON DELETE CASCADE,
`name` varchar(70) default NULL,
`content` varchar(240)
);

-- Отдельная таблица хранит связи между родительским сообщением и ответами
-- на него. Каждая такая связь создаётся единожды (либо тоссером с приходом
-- новой почты, на основе анализа кладжей msgid и reply, либо редактором
-- почты или WebBBS-интерфейсами, по мере создания новых ответов), зато
-- может быстро и многократно использоваться при построении древовидных
-- структур обсуждения. Связи уничтожаются автоматически по мере того,
-- как исчезает в них нужда (этой цели служит каскадное удаление).

CREATE TABLE `parent2children` IF NOT EXISTS (
`parent` INTEGER REFERENCES messages (id_msg) ON DELETE CASCADE,
`one_of_children` INTEGER REFERENCES messages (id_msg)
ON DELETE CASCADE,
);

-- Конец схемы.

────────────────────────════════╪══╬═╣()╠═╬══╪════════────────────────────────

В этом (прошлогоднем) виде мой черновик не учитывает ещё разумную необходимость
декодирования UUE-кодов тоссером, и сохранения декодированных файлов в файловой
системе (на диске) или в BLOB-полях некоторой отдельной таблицы в базе данных.

Также, возможно, таблицу flagdata можно сильно сократить, вместо ряда двоичных
полей создать единственное с битовыми масками. Тогда база будет компактнее, но
поиск по этому будет идти через наложение маски на поле, так что замедлится.

Таблицу messagetexts можно выделить в отдельный файл вообще ── для надёжности
и для ускорения работы в тех случаях, когда тексты сообщений не при чём, когда
работа идёт только с заголовками (например, когда идёт построение списка).

Если ты примешь этот формат, то тебе есть смысл не встраивать тоссер в FBR,
а создать его отдельно, так как такой формат базы может пригодиться для других
целей и других читальников фидософта.

Если будут какие-либо свои соображения по поводу того, где этот формат можно
подправить и переменить, или почему он вообще неприемлем, то высказывай их.


Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/
Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]

... 195. I will not use hostages as bait in a trap.

Loading...