>
>      К сожалению российские производители железа очень
>неохотно делятся протоколом работы по ком-порту (а у некоторых процедура эта
>заморочена до нельзя (тос-элкос борисоглебский к примеру))
Не работал с таким. Но неужели там что-то менее тривиальное чем просто чтение данных?
>
>>Таким образом, алгоритм добавления новой АТС примерно такой:
>
>      Ну дык при готовых логах со
>станции и остается поправить perloвый скрипт
Править ничего не надо - просто добавляем новую библиотеку и подключаем её в конфиге.
>
>>Некоторые станции (особенно это любит панасоник) имеют несколько вариантов (до 5!) отдачи логов. Обычно они описаны в документации и могут быть автоматически определены
>>в регекспах, но желательно этот вариант проверять и учитывать, так как
>>другой пользователь может иметь другие настройки. Кроме того, иногда SMDR зависит
>>от версии прошивки (!), но это, к счастью, скорее исключение.
>
>      Кстати, а нет желания у автора
>переехать с php на rubyonrails ? Многие бы вопросы отпали, а
>многие упростились :) с SQLlite и прочими sql движками - вопрос
>решится сразу, на порядок проще разработка, подключением соотв. плагинов элементарно решаются
>вопросы аутентификации - от простейших до role-based, ajax - элементарно. Короче,
>ROR это просто красиво - красиво писать и красиво эксплуатировать.

Нет, не было. Потому как проект не из 5 строк, и это задача ну совсем не на 1 день работы.

Кроме того:
1) Я абсолютно не вижу каким образом "решится сразу вопрос с SQLite". Для того, чтобы заработал SQLite требуется немного изменить часть запросов, добавить некоторые ф-ии, поправить парсер конфигурационного файла, документацию, atslogdb.pl и сопутствующие материалы. Часть этой работы уже сделано, и вероятнее всего SQLite поддержка будет в версии 2.1.x. Никоим образом переход на другой язык программирования это не ускорит. Потому как всё равно используется abstraction layer (adodb для php и DBI для perl) с поддержкой SQLite. Правда, SQLite будет работать только в PHP5.

2) Вопросы аутинтефикации уже вобещм-то успешно решены, ну единственное что - в 2.1 думаю сделать form based auth, а не http based, так как с последней много всяких проблем.

3) Что касается красоты кода - уверен, что в 1, 2 и 3 очередь это зависит от автора, а не от инструментария. В текушем виде код явно требует рефакторинга, но на мой взгляд - это не первоочередная задача. Если не обламаюсь, в будущем реалтзую MVC, прикрутив SMARTY для шаблонов и вынесу всю математику в отдельный класс.

Вобщем, если у вас будет желание сделать интерфейс, хотя бы с текущей функциональностью, на RoR и он окажется лучше и удобнее существующего - мы добавим его в проект. А просто давать советы в форумах - это любой cможет.

P.S. Я знаю и PHP (Zend Certified developer) и достаточно много писал JSP страниц, и даже на всякой экзотике, типа server-side javascript или rexx, писать приходилось. И моё мнение, что красота кода в первую, вторую и десятую очередь зависит от разработчика, а не от инструмента. И меньше всего люблю религиозные войны о том, какой язык круче. Хочешь показать крутость языка - напиши на нём что-то удобное и полезное. А скулёж из серии "билл гейстс ууууу!" или "пых-пых сосёт" обычно устраивают те, кто в принципе ничего кроме телег на форумах не пишет, да.