Добрый день!

Предложение в первую очедь к разработчикам системы ИРБИС! Но я надеюсь, что меня поддержат и другие участники форума!

ПРЕДЛОЖЕНИЕ:

Предложение состоит в том, что бы ввести в ИРБИС возможность подключения сторонних модулей.

ВВЕДЕНИЕ В ПРОБЛЕМАТИКУ (или зачем это нужно):

Сейчас пока ИРБИС выступает как закрытая проприетарная система обладающей ограниченными возможностями расширения функциональности и интеграции в уже готовые технологические иформационые процесс бибилиотеки.

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

Даже при всем желании разработчики ИРБИС не в состоянии учесть все нюансы и тонкости всех библиотек. Но ведь это на самом деле и не нужно. Было бы просто достаточно, что бы в ИРБИСЕ появилась возможность подключения внешних модулей. Тогда любые нюансы работы библиотеки могли бы реализовывать собственными силами и более того, делится своими наработками с другими библиотеками, тем самым только повышая популярность самого ИРБИС!

Более того, внедрение в ИРБИС плагинов, позволит разработчикам не только значительно повысить функциональность ИРБИС, но и использовать для тюннинга ИРБИС свои отточенные средства разработки. А также использовать языки высокого уровня заточенные для решения сложных объектных задач, в отличие от все-же примитивного и nonusability (да простят меня создатели) pft.

КОНКРЕТНЫЕ ПРИМЕРЫ:

1.

Например, в нашей библиотеке есть развитая система "книгообеспеченность" собственной разработки, которая разрабатывалась в течении несколько лет (она начала развиваться еще тогда, когда у нас не было ИРБИС) и которая полностью удовлетворяет нашим потребностям.

В свою очередь, средств самого ИРБИСА пока очень не достаточно, что бы на нем можно было бы развернуть "книгообеспеченность" сравнимого по масштабу и функциональности.

Сейчас для синхронизации каталогов ИРБИС и "Книгообеспеченности" (MSSQL) приходится выгружать и синхронизировать каталоги целиком, что само по себе затратная по времени процедура и, что неприятно, еще и пораждает нестыковки, т.к. происходит не в реальном времени.

Если бы в ИРБИС существовала бы возможность подключить собственный модуль (dll) на событие сохранения записи, то можно было бы автоматически синхронизировать эту запись с нашей системой "книгообеспеченность".

2.

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

Сейчас же библиографу приходится преключаться между двумя программами, следить за синфазностью действий.

Было бы очень здорово, если бы в ИРБИС существовала бы возможность подключить собственный модуль/плагин на событие сохранения записи. В этом случае, можно было бы автоматом генерировать штрих-кода, проставлять их автоматом в нужные поля и автоматически запускать программу печати нужного штрих-кода. И все это счастье, производилось бы автоматически всего при нажатии на кнопку "сохранить запись".

3.

У каждой развитой библиотеки есть сайт в интернет. Поиск фонде и заказ книг онлайн позволяет делать Web-Irbis и это просто прекрасно.

Однако, например на сайте нашей библиотеки по многолетней традиции выставляются на сайте в специальном разделе (как открытый ресурс) полные тексты статей проводимых в нашем институте научных сессий. Публикация на сайте делается с помощью скриптов на PHP и использованием MySQL. Опять же приходится выгружать весь каталог и заливать его в MySQL.

А как было бы замечательно, если бы при каждом сохранении/корректировки библиографом, бибописание автоматически корректировалось бы и на сайте. Это опять же можно было бы легко сделать, если бы к Ирбису можно было бы на событие сохранения подключить собственный модуль, который бы автоматом заливал необходимую информацию в MySQL базу.

-

И таких примеров можно набрать массу... Там же и сложные аналитические отчеты по базам, которые у нас пока реализованы на Perl скриптах и где всецело используется мощный аппарат Regular Expressions (отсутствующие как класс в pft), да и сама гибкость и usability языка Perl значительно превосходит pft.

ТЕХНОЛОГИЧЕСКИЕ ПРЕДЛОЖЕНИЯ:

1. ИРБИС Framework

Если ИРБИС преобразовать по структуре в Framework, которая бы вызывала и регистрировала внешние модули, а также представляла им развитый объектный API.
- То фактически конечные разработчики получили бы практически безграничные возможности по наращиванию и изменению функцональности стистемы, в частности даже непосредственного изменения интерфейса программы.
- А сами разработчики ИРБИС получили бы полную свободу в выборе и даже изменении технологической основы для системы, без страха навредить своим пользователям.

Таким образом ИРБИС можно было бы сделать полностью модульным и достичь вожделенной развязки технологии от представления данных и обеспечить удивительную гибкость и богатейшие возможности развития продукта за счет внешних подключаемых модулей.

2. Классические плагины

Если ИРБИС позволит подключать плагины (dll) и вешать их на отдельные события (ON_RECORD_SAVE, ON_UPDATE и т.п.), а также пересылать им указатели на текующую запись, для возможности считывания или коррекции до попадания в базу.

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

Возможно это был бы самый оптимальный вариант, как для пользователей системы, так и разработчиков (т.к. писать совсем не много, особенно для ИРБИС 64, где уже есть клиент-серверная архитектура)

3. Ну и как простой вариант - хотябы запускать собственные функции из pft с возвращением результата в формат.

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

--------------------------------------------
Вопрос подключаемых сторонних модулей - это действительно очень важный момент, которого очень сильно не достает в современном ИРИБИС. И я очень надесь, что разработчики ИРБИС обратят на него достойное внимание, тем более, что это сделает ИРБИС значительно лучше!

Надеюсь меня поддержат и другие пользователи ИРБИС!

С уважением, Владимир Ким
Инженер-программист НБ МИФИ

Мой ответ - в ветке ВЕРСИЯ 2006.1 (новый UNIFOR)

см. [irbis.gpntb.ru]

Здесь лишь одно замечание.
Абсолютно некорректно сравнивать язык форматирования (pft) c Perl, PHP и т.п. Язык форматирования - это НЕ ЯЗЫК ПРОГРАММИРОВАНИЯ (т.е. не процедурный язык), а только лишь язык манипулирования данными...

Киму - по поводу автоматической генерации штрих-кодов и в связи с новым unifor('+8...

Если Вам надо автоматически создавать штрих-коды при сохранении записи, то безусловно вы должны воспользоваться autoin.gbl с вставкой в него нового unifor('+8... Но при этом важно понимать, что autoin.gbl отрабатывает ДО сохранеия записи.

Можно предложить следующую конструкцию для вставки в autoin.gbl

REP
910
F
(if p(v910) then v910, if a(v910^H) then '^H',&unifor('+8AAA,BBB,',mfn,/v910) fi fi/)

где
AAA - имя Вашей DLL
BBB - имя Вашей процедуры, генерирующей штрих-код
mfn,/v910 - это примерные передаваемые данные, которые нужны для генерации штрих-кода ТЕКУЩЕГО экземпляра (если нужно что-то еще, то соответственно надо передавать другие данные)

Если речь идет еще и об одновременной печати сгенерированных штрих-кодов то....

это может делать та же Ваша функция ВВВ - но при этом, наверно, будет неудобно то, что она будет печатать ЕДИНСТВЕННЫЙ штрих-код.
Если есть необходимость печатать сразу всю группу штрих-кодов для всех экземпляров одного издания, то можно предлжить более сложные конструкции...

REP
910
F
&unifor('+7W99#'),(if p(v910) then v910, if a(v910^H) then &unifor('+7U99#',&unifor('+8AAA,BBB,',mfn,/v910)),'^H',G99 fi fi/),&unifor('+8AAA,CCC,',(G99/))


Здесь дополнительно все генерируемые штрих-коды накапливаются в повторяющейся глобальной переменной 99 (ее надо выбрать уникальной, чтобы не пересечься с теми, которые уже используются в autoin.gbl), которая затем передается в другую Вашу функцию ССС, печатающую группу штрих-кодов. (при этом важно, чтобы функция ССС НИЧЕГО не возвращала)

(Примеры написаны "на скорую руку" - поэтому нуждаются в проверке...)

Добрый день!

Еще раз искренне благодарю Вас за отзывчивость и внимание к пользователям!

>>Но при этом важно понимать, что autoin.gbl отрабатывает ДО сохранеия записи.
Это то что нужно, т.к. помимо печати штрих-кода нужно еще и вставить его в соответствующее поле, а уж потом разрешить сохранение.

>>Можно предложить следующую конструкцию для вставки в autoin.gbl
Большое спасибо за пример!

Скажите, а уже сейчас можно будет использовать новый UNIFOR в ирбис 64? Есть у Вас возможность прислать обновленные DLL, что бы можно было бы уже попытаться что-то сделать или только ждать нового релиза?

С уважением Владимир Ким
Инженер-программист НБ МИФИ

PS: Надеюсь, когда нибудь дождемся и настоящий ИРБИС Framework :)
PS2:
>>Здесь лишь одно замечание.
>>Абсолютно некорректно сравнивать язык форматирования (pft) c Perl, PHP и т.п. Язык форматирования - это НЕ ЯЗЫК ПРОГРАММИРОВАНИЯ (т.е. не процедурный язык), а только лишь язык манипулирования данными...

XML имеет развитые технологии представления/форматирования данных - XSLT (плюс еще DOM/XPath - это уже вкусности самого XML), это как пример развитого языка форматирования данных...

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

> Абсолютно некорректно сравнивать язык форматирования (pft) с Perl, PHP и
т.п. Язык форматирования - это НЕ ЯЗЫК ПРОГРАММИРОВАНИЯ (т. е. не
процедурный язык), а только лишь язык манипулирования данными...

ВОЗРАЖЕНИЯ:
1. Теоретически это правильно, но в жизни такой четкой границы часто нет. Примеры:
1.1. HTML давно уже не то, чем он был вначале, т. е. только «языком разметки гипертекста» с появлением макросов, фреймов и т. д.
1.2. PHP (кажется, расшифровывается как «Препроцессор гипертекста») вроде бы и не язык программирования, и не язык форматирования?
1.3. Язык программирования иногда используется и как средство формирования выходных форм. На форуме в этой связи упоминался Руслан и «применяемый в нём для форматирования Си-образный язык» (© К.Соколинский). То же относится к Библиотеке 4.0/5.0 и соответственно Clipper/Visual Objects.
2. Тот факт, что язык форматирования ИРБИС - это не язык программирования, не противоречит тому мнению, что он устарел, «неюзабелен» и малочитабелен (ведь последнее обстоятельство признает и сам Александр Иосифович в связи с включением в него команд HTML)

> Сейчас пока ИРБИС выступает как закрытая проприетарная система

УТОЧНЕНИЕ: термины «закрытый» и «проприетарный» обычно используют сторонники «свободного софта», т. е. открытых «исходников» и бесплатности, в основном «линуксоиды». Но к написанию и подключению плагинов это не имеет отношения. Самые известные примеры: по количеству плагинов на первом месте (если не ошибаюсь) — закрытый, проприетарный и недешевый Photoshop, на втором (если не ошибаюсь) — закрытый и проприетарный (хотя и бесплатный для xUSSR) FAR.

> Не секрет, что у каждой более-менее развитой библиотеки имеются
собственные программные разработки

КОММЕНТАРИЙ: у очень немногих… если, конечно, не считать давно забытые «самопальные» недоработки начала 1990-х, обычно на FoxPro, а чуть позже на Excel и Access, безо всякого экспорта-импорта и т.д.

> делится своими наработками с другими библиотеками, тем самым только повышая популярность самого ИРБИС!

ПРЕДЛОЖЕНИЕ: а каким способом? Для этого, кажется, предназначен раздел сайта ЭБНИТ «Опыт и разработки пользователей», который по-прежнему почти пуст. А ведь вроде бы это и есть самое место для пользовательских расширений. А потом устроить «хит-парад» с моральном поощрением разработчиков наиболее скачиваемых разработок :)!!!

> средств самого ИРБИСА пока очень не достаточно, что бы на нем можно было бы развернуть "книгообеспеченность" сравнимого по масштабу и функциональности.

КОММЕНТАРИЙ: А вот г-н Карауш когда-то писал, что наоборот, что «у них» (в смысле не в Томске, а наоборот, на Западе) вообще нет никаких систем или модулей книгообеспеченности, и что наши разработчики выдумали себе эту задачу искусственно, только для увеличения своих доходов… а теперь оказывается, что совсем наоборот… и это притом, что АРМ «Книгообеспеченность» ИРБИСа постоянно совершенствуется…

> Сейчас для синхронизации каталогов ИРБИС и "Книгообеспеченности"
(MSSQL) приходится выгружать и синхронизировать каталоги целиком […]
Если бы в ИРБИС существовала бы возможность подключить обственный
модуль (dll) на событие сохранения записи, то можно было бы автоматически синхронизировать эту запись с нашей системой "книгообеспеченность".

ВОПРОС: а разве не имеет значения то, что структуры файлов данных ISIS/ИРБИС и MS SQL совершенно разные?

Совсем не понял насчет синхронизации "главного" ЭК и ЭК на сайте
Не лучше ли просто регулярно копировать данные из ИРБИСа в Веб-ИРБИС, например, старым добрым батничком типа
copy c:\irbis\datai\*.* d:\webirbis\*.*
+ планировщик (например, «Назначенные задания» Windows)
А если это кажется немодным или несолидным, можно использовать многочисленные системы резервного копирования, например, бесплатный IsisBackup А.С.Карауша

> на сайте нашей библиотеки по многолетней традиции выставляются на сайте […] полные тексты статей […]. Публикация на сайте делается с помощью скриптов на PHP и использованием MySQL. Опять же приходится выгружать весь каталог и заливать его в MySQL.
А как было бы замечательно, если бы при каждом сохранении/корректировки библиографом, биб. описание автоматически корректировалось бы и на сайте. Это опять же можно было бы легко сделать, если бы к Ирбису можно было бы на событие сохранения подключить собственный модуль, который бы автоматом заливал необходимую информацию в MySQL базу.

ВОПРОСЫ:
1. см. предыдущий вопрос
2. непонятно, о чем здесь говорится — о полных текстах, о библиографических описаниях и об их интеграции?

> Там же и сложные аналитические отчеты по базам…

КОММЕНТАРИЙ: подтверждается правильность моего предложения о разработке АРМа «Статистика»

Я, конечно, ужасно извиняюсь, но все-таки прошу уточнить: полностью ли вызов функций из внешних dll реализует идею плагинов? Иначе говоря, это все-таки одно и то же или нет?

Это немного разное. Плагин подразумевает под собой, что, подключенный, он может влиять на работу самого приложения. Самый яркий пример: обычно плагины добавляют собственные пункты меню в приложение.
Реализованные dll - это просто очень гибкий механизм форматирования. Хотя в какой-то мере они являются плагинами.

> полностью ли вызов функций из внешних dll реализует идею плагинов?

Такое сделать можно средствами dll, но вначале нужно описать функции, чтобы можно было менять dll "на ходу", не перекомпилируя всякий раз проект под новую dll.
Я не понимаю, почему не попросить у Александра Иосифовича исходники format32.dll и прописать туда свои функции, а потом про них написать и сделать лучше для других пользователей. Обязательно нужно писать в форум, что ИРБИС закрытая! А кто ее просил открыть для профессионального использования? Или хотите, чтобы коды были "на заборе" все написаны?
Придумайте интерфейс (хотя бы предложите), опишите его, и если он будет стабильно работать, то внедрить его хоть для dll, хоть для COM уже будет более реально. Просто предлагать-то никто не хочет идеи.

Теперь про "Книгообеспеченность". Ну нет в западных системах такого модуля. Искал и не нашел, что в Aleph, что в VTLS, что в SIRSI. У них там все просто, если преподаватель сказал надо, значит - надо. А если книга не спрашивается, то преподаватель - жестоко отвечает за свои слова, почему он потратил чужие деньги. Все остальное, что не куплено, студенты ОБЯЗАНЫ купить сами на свои кровные. И никто их ни по какому договору не обязан снабжать литературой нахаляву. Сам по этой проблеме беседовал с директором библиотеки Теннессийского университета. Мне привели в пример группу, где каждый студент платит за обучение по 55 тыс.дол. в год, и 80% литературы они покупают сами. Вот и посудите, зачем прагматичным американцам не то, что покупать, а разрабатывать модуль, который непонятно для чего им нужен.
80% пользователей у нас покупают книгообеспеченность, чтобы отвязались проверяющие, поскольку у многих есть свои менее затратные способы ответить на простой вопрос: "Достаточно ли книг по той или иной тематике имеется в библиотеке?"
И как показывает практика, делать расчет кнгообеспеченности в наших условиях постоянной смены программ, курсов, наборов, да еще с динамическими установками-отборами грифов - настолько затратное дело, что намного проще рисовать эти цифры "с потолка", тем более, что для фонда в 1000-2000 наименований профессиональный библиограф с точностью 10% вам книгообеспеченность "на глаз" скажет за пару дней.

Хотя, все хочется посчитать, особенно в тысячных долях, хотя насколько все эти цифры будут отражать реальность - это уже совсем другая тема ;)

>> Сейчас пока ИРБИС выступает как закрытая проприетарная система

>УТОЧНЕНИЕ: термины «закрытый» и «проприетарный» обычно
>используют сторонники «свободного софта», т. е. '
>открытых «исходников» и бесплатности, в основном «линуксоиды». Но
>к написанию и подключению плагинов это не имеет отношения.

Я лишь имел ввиду сейчас ИРБИС выступает и как закрытая и как проприетарная система - т.е. хотел подчеркнуть, что к ИРБИС сейчас не подступишься ни с какой из сторон.

>> Сейчас для синхронизации каталогов ИРБИС
>>и "Книгообеспеченности"
>>(MSSQL) приходится выгружать и синхронизировать каталоги
>>целиком […]
>ВОПРОС: а разве не имеет значения то, что структуры файлов данных
>ISIS/ИРБИС и MS SQL совершенно разные?

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

>>Совсем не понял насчет синхронизации "главного" ЭК и ЭК на сайте
>>Не лучше ли просто регулярно копировать данные из ИРБИСа в Веб-
>>ИРБИС, например, старым добрым батничком типа[...]

Некоторые из необходимых функций не доступны из web Ирбиса.

Допустим мы захотим на главной странице сайта разместить информацию о количестве выдач за сегодня... Как это можно сделать стандартными средствами? А если бы можно было повесить плагин на определенное событие в ИРБИС, то можно было написать простой плагин, который выдавал бы на сайт необходимую информацию.

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

>> на сайте нашей библиотеки по многолетней традиции выставляются
>>на сайте […] полные тексты статей […]. Публикация на сайте
>>делается с помощью скриптов на PHP и использованием MySQL.

ВОПРОСЫ:
1. см. предыдущий вопрос
2. непонятно, о чем здесь говорится — о полных текстах, о библиографических описаниях и об их интеграции?
[library.mephi.ru]

С уважением, Владимир Ким
-------------------------------------
Инженер-программист НБ МИФИ

Уважаемый Александр Сергеевич,
а как это менять dll "на ходу"?
Выходим из ИРБИСа, прописываем новую dll в autoin.gbl или в <dbn>.fst, снова запускаем ИРБИС? Но это никак не “на ходу”, а совсем наоборот…
О чем-то похожем я уже писал (см. “Версия 2006.1”), а теперь пишу в новой редакции:
нужно иметь много внешних dll или много функций внутри одной dll, из которых, например, каталогизатор выбирал бы нужные. Но поскольку новый UNIFOR включается в autoin.gbl или в <dbn>.fst, такой выбор невозможен
Может быть, это (или что-то вроде) можно сделать, реализовав (с уточнениями) Ваше предложение от 05-08-04: запуск внешних программ макрос-кнопками; они должны работать как глобальная корректировка, которая будет для всех найденных или отмеченных записей производить одну и ту же последовательность действий с возможностью задавать действия и количество кнопок?

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

Про макрос-кнопки я писал только затем, что есть желание часто используемые кнопки вытаскивать на отдельную панель. В ИРБИС64 это реализовать можно, убрав с панелей лишние кнопки.

Но как же все-таки, например, каталогизатор сможет выбирать нужные dll или нужные функции?



Отправка отредактированного (06-05-06 12:25)

2В.Ким
Насчет публикации полных текстов на сайтах. Но ведь все известные разделы сайтов, озаглавленные "Электронная библиотека" или "Электронные издания" - это просто наборы html-страниц (или PDF, DOC) или даже просто списки ссылок, например, упомянутый Вами
[library.mephi.ru]
или [library.timacad.ru]
(здесь есть ссылки на сайты ГПНТБ и МУБиНТ:))
безо всяких БД, СУБД или АБИС.
Web-ИРБИС64ПТ пока, кажется, никто не использует, о других подобных системах (модулях) неизвестно - конечно, если не считать небиблиотечные полнотекстовые базы, например, справочно-правовые с собственными оболочками.



Отправка отредактированного (06-05-06 13:55)

2АСК: более того, в 32-м тоже можно убирать некоторые кнопки путем редактирования файла irbismsg.txt. Например, в Читателе этим способом можно убрать кнопку «Экспорт». Но ни в одной версии нельзя добавлять свои (advanced users’) кнопки…

Прошу уточнить на всякий случай: format32.dll из текущей демо-версии, видимо, не содержит этих новых функций?

Это только в FORMAT32.DLL для версии 2006.1

Тема закрыта? За ненадобностью? Или за отсутствием энтузиастов?