ANS>> модули squish и jam надо причесать к общему знаменателю, чтобы ANS>> конечному пользователю модулей не приходилось использовать ANS>> readJDX,readSQI, а что-то типа readIndex. и даже это лишнее. ANS>> достаточно .getSize(), которая внутри сама вызовет нужное.
MW> Совершенно верно, совершенно верно. До известной степени MW> node-fidonet-jam примерно так и организован: методы более высокого MW> уровня вызывают методы более низкого уровня. Вот десяток примеров MW> этого, взятых из README-файла:
<skip> а size() не вызывает readJDX, вследствие чего костыль в fido2rss в виде readJDX :-)
ANS>> пока ещё рано. будет как-то так : ANS>> somemailer->fidonet-config->some-modules ANS>> |->fidonet-outbound->some-modules ANS>> (fidonet-outbound-bso,fidonet-outbound-lbox уже ANS>> есть) ANS>> |->fidonet-mailer->some-modules ANS>> |->fidonet-interface->some-modules MW> У меня сразу три таких вопроса: MW> *) Понятно, что fidonet-mailer ── это подсистема somemailer. Только ли MW> транспортный модуль это (реализация binkp) ── или и ещё что-нибудь MW> также? чего угодно. хоть модемного emsi/iemsi.
MW> *) Каким ты видишь набор возможностей fidonet-config и чем он выходит MW> за пределы нынешних возможностей simteconf? тем, что кроме как чтение конига binkd можно сделать чтение конфига любого мейлера, в том числе бинарного.
MW> *) Фреки будут? И более того: возможен ли такой режим binkp-модуля, в MW> котором MW> он ТОЛЬКО фрекает, а нефрекаемым файлам (бандлам почты, содержимому MW> файлэх MW> и т. п.) говорит: полежите-ка ещё на холде? конечно всё это можно реализовать. сначала обычный до конца реализую. завтра попытаюсь режим сервера добавить к модулю.
