Опубликована новая версия WEB ИРБИС32 на сайте ГПНТБ в разделе
Каталоги и базы данных.

Электронный Каталог ГПНТБ, база данных авторефератов диссертаций и Сводный Каталог.

По прямой ссылке:
[www.gpntb.ru];

Новая версия целиком соответствует WEB ИРБИС64 5.2.
Получение новой версии возможно на общих условиях годового сопровождения системы ИРБИС.

У меня два вопроса:
1.Где режим рассылки?
2.Обеспечена ли в новой версии полная поддержка WIN 1251 кодирокви?

>>>>два вопроса:
>>>>1.Где режим рассылки?

Этого режима нет и в WEB ИРБИС64.
В WEB ИРБИС32 он проходил как пример.
Впрочем, все функции этого режима (запись в БД) работают.

>>>>2.Обеспечена ли в новой версии полная поддержка WIN 1251 >>>>кодировки?

Здесь все как в ИРБИС64.
Кодировка фреймов - UTF-8 для поддержки диакритов, которые могут вводится в ИРБИС32.
Фреймы можно держать в кодировке WIN 1251, но это совершенно напрасный труд, так как шлюз на выходе все переведет в UTF-8.
Попытка сэкономить врямя загрузки на размерах фреймов, составляющих (в сумме!!) несколько десятков килобайт, просто смехотворна.
Лучше поработать с дизайном сайта, так как обычно именно видеоряд забирает в десятки раз больше памяти, чем текстовая инфомация.

> Здесь все как в ИРБИС64.

Да, только с той разницей, что применительно к ИРБИС 64 некоторые из этих решений имеют оправдание, а к ИРБИС 32 - нет.

> Попытка сэкономить врямя загрузки на размерах фреймов,
> составляющих (в сумме!!) несколько десятков килобайт, просто смехотворна.

«Смехотворной» является:
1. Практика передачи пользователю удвоенного объёма информации.
2. Возможность хранения фреймов в WIN 1251, но невозможность после этого нормальной работы с запросами(см. Проблема смены кодировки) .
3. Необходимость использовать для вывода и перекодировки текстовых строк из формата спец функции.
4. Необходимость применять форматы только ради корректного отображения информации(см. FAQ.DOC в базовой поставке)
5. Необходимость отказа от распространённых средств редактирования исходного кода.
6. Необходимость грузить 64 килобайтовый UTF8 интерфейс при каждом обращении к рубрикатору или УДК.
7. Попытка применения для редактирования фреймов базовой поставки визуальных редакторов и отказ от использования CSS. (<td valign="Center"><div align="Right"><font color="#3333ff"><b>)
8. Практика создания новых элементов интерфейса путём копирования имеющихся, без просмотра получившегося результата.

Вот, например, эта кнопка должна всего лишь вставлять И в поисковый запрос:
<input type="submit" class="inp1" name="C21COM" value="И" onclick="return PasteLogic_AND()" style="width: 100%; ">
Она не имеет никакого отношения к параметру C21COM или отправке формы(submit). Просто скопировать имеющуюся кнопку оказалось легче, чем создавать новую. . . . Можно себе представить как это должно удивить тех, кто в первый раз увидеть новую версию...

Полагаю, список новых «преимуществ» полученных от UTF в IRBIS 32 вы могли бы продолжить сами.

> Кодировка фреймов - UTF-8 для поддержки диакритов, которые могут вводится в ИРБИС32.

Укажите хотя бы на три библиотеки, которые используют диакриты в IRBIS 32!


> Фреймы можно держать в кодировке WIN 1251, но это совершенно напрасный
> труд, так как шлюз на выходе все переведет в UTF-8.

Спасибо за напоминание, это я уже понял, и даже писал о своих впечатлениях раньше. . .

> Лучше поработать с дизайном сайта, так как обычно именно видеоряд
> забирает в десятки раз больше памяти, чем текстовая инфомация.

Вся графика моего сайта весит 7 килобайт. Вряд ли это сравнимо с 64 килобайтами вашего текстового интерфейса. Кроме того, графика скачивается 1 раз и кэшируется, а текст всегда качается заново.

Я очень хочу, чтобы вы, Константин Олегович хорошо осознали:
ВЫ ПЫТАЕТЕСЬ СЭКОНОМИТЬ СВОЁ ВРЕМЯ И СВОИ СИЛЫ ЗА СЧЁТ ВРЕМЕНИ И СИЛ ПОЛЬЗОВАТЕЛЕЙ И АДМИНИСТРАТОРОВ ВАШЕЙ СИСТЕМЫ.

Кирилл. Тут я, пожалуй, соглашусь с Константином Олеговичем. Схема сделана универсально. Причем с упором на Ирбис64, поскольку это уже базис, а не 32. Следовательно если делать 2 варианта настройки, то все получистя еще более запутано и не понятно. При универсальном подходе всегда приходится чем-то жертвовать. И уж те самые 64 кб не конец света! Лишние 2-3 секунды при загрузке погоды не сделают.
По этому тут экономия не только сил разработчиков, но и сил пользователей, которые после 32, рано или поздно, перейдут таки на 64 и вот тут то они, да и вы наверное, скажете спасибо за то, что все универсально.

Панев Максим писал(а):

> Кирилл. Тут я, пожалуй, соглашусь с Константином Олеговичем.
> Схема сделана универсально. Причем с упором на Ирбис64,
> поскольку это уже базис, а не 32. Следовательно если делать 2
> варианта настройки, то все получистя еще более запутано и не
> При универсальном подходе всегда приходится чем-то
> жертвовать. И уж те самые 64 кб не конец света! Лишние 2-3
> секунды при загрузке погоды не сделают.
> По этому тут экономия не только сил разработчиков, но и сил
> пользователей, которые после 32, рано или поздно, перейдут таки
> на 64 и вот тут то они, да и вы наверное, скажете спасибо за
> то, что все универсально.

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

Впрочем, в своём сообщении я говорил не только и не столько об универсальности...

В ближайшее время планируется переход ИРБИС32 на структуру баз данных ИРБИС64.
Это даст необходимые преимущества по совместимости версий и решит проблему многоязычия. Требования к поддержке unicode выдвигают едва ли не 90% пользователей ИРБИС.
Версия WEB ИРБИС32 прекратит свое существование.

> В ближайшее время планируется переход ИРБИС32 на структуру баз данных ИРБИС64.

Вы вполне уверены в том, что написали? Вы хотите сказать, что файл-серверная IRBIS 32 будет переведена на UTF8 и новую структуру данных? Вы утверждаете, что ГПНТБ планирует поддерживать две ветки ИРБИС, которые будут построены на новых принципах, но тут же противоречите себе:
> Версия WEB ИРБИС32 прекратит свое существование.


> Это даст необходимые преимущества по совместимости версий и решит проблему многоязычия.

Использование UTF8 при каталогизации и для хранения данных - это разумное и перспективное решение. Никто с этим не спорит. Но речь идёт не об этом, а о том, как ПЕРЕДАВАТЬ И ПРЕДСТАВЛЯТЬ информацию пользователю. Не нужно оправдывать недоработки перспективностью UTF8. Я утверждал, что даже библиотека применяющая ИРБИС 64+WEB может предпочесть использовать для представления в WWW своих каталогов WIN кодировку. Заметьте, самый веский аргумент в пользу этого выдвинул не я, а Александр Сергеевич. Вы можете объяснить, как пользователи будут вводить диакриты при поиске? Где у вас предусмотрена виртуальная клавиатура?

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

Наконец, главным для меня был вопрос: С КАКОЙ ЦЕЛЬЮ ПОЛЬЗОВАТЕЛЯМ ПРЕДОСТАВЛЯЕТСЯ ВОЗМОЖНОСТЬ ХРАНЕНИЯ ФРЕЙМОВ В WIN, ЕСЛИ СИСТЕМА НЕ МОЖЕТ ПОСЛЕ ЭТОГО НОРМАЛЬНО РАБОТАТЬ? (см. Проблема смены кодировки)

> Требования к поддержке unicode выдвигают едва ли не 90% пользователей ИРБИС.

Я высказал утверждение, что возможность самостоятельно выбирать кодировку сайта будет востребована библиотеками. В своём ответе мы выразили сомнение, что это так и фактически заявили о том, что 10%(по вашему предположению) библиотек, которые не используют диакриты можно пренебречь.
В Петербурге, если мне не изменяет память, ИРБИС использует около 50 библиотек. Вы готовы назвать хотя бы 40, которые не могут жить без UNICODE?

PS
У меня нет сомнений в бесперспективности IRBIS 32, но есть большие сомнения в перспективности IRBIS 64. В таком «логическом тупике» находится сегодня большинство библиотек. Если ветка IRBIS 32 перестанет развиваться, большинство библиотек просто откажется от сопровождения(если конечно, для них не имеет значения сам по себе контакт с дилером) или перейдёт на другие системы(Руслан, например).
Данные вопросы я не готов сейчас обсуждать. По этому поводу можно написать большой трактат.



Отправка отредактированного (12-01-06 15:51)

Планируется 2 версии ИРБИС
файл сервер и клиент сервер
Обе версии имеют совершенно одинаковый интерфейс отличие только в доступе к БД
Структура баз данных ИРБИС64

В шлюзе ИРБИС32 используется бразильская библиотека доступа isis32.dll и форматирование через код format32.dll
Унифицировать доступ к ИРБИС64 и ИРБИС32 поэтому достаточно сложно и сама эта задача сравнима с разработкой шлюза

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

Константин Сбойчаков писал(а):

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

Да, да, совершенно верно! Очень рад вашему решению! Я, да и остальные пользователи, полагаю, готовы забыть о всех проблемах с интерфейсом, форматами, рубрикаторами и т. п. Это первоочередное и самое важное. Если в новой версии устранены проблемы с зависаниями, кодировки и безопасность - приоритеты номер 1 и номер 2.

Повторю еще раз. Возможность менять выходную кодировку - согласен, но только для конкретной базы. К тому же должна быть возможность хранить все в едином формате (UTF8), а при необходимости конвертить результат в win1251.
Минимальные требования по правам доступа: сделайте ФЛК и там можно будет прописать хоть черта лысого!!!

Привязать выходную кодировку к базе данных сложно.
Необходимо, чтобы она совпадала с кодировкой фреймов.
В этом случае ВСЕ параметры запроса должны подаваться в этой кодировке КРОМЕ, возможно, параметров QUERY (так как эти параметры в любом случае должны быть дополнительно закодированы в последовательность URI (%HEXCHAR) ).
Поэтому остаются работающими 2 параметра ини файла шлюза -
FRAMES_CHAR_SET
QUERY_CHAR_SET
Единственное, что я не смогу сделать, это держать дистрибутив в двух вариантах. Поэтому каждому, кто захочет использовать НЕ UTF-8 предстоит утомительная работа по переводу фреймов - ини-файла - файла со строками ошибочных сообщений в нужную кодировку.

Константин Сбойчаков писал(а):

> Привязать выходную кодировку к базе данных сложно.
> Поэтому каждому, кто захочет использовать НЕ
> UTF-8 предстоит утомительная работа по переводу фреймов -
> ини-файла - файла со строками ошибочных сообщений в нужную
> кодировку.

Я подключил 4 базы, предусмотрел 3 режима поиска и это потребовало всего 17 фреймов. Не могу сказать, чтобы их конвертирование было для меня слишком трудной задачей. :) Полагаю, что другие пользователи тоже смогут его провести, поэтому перекодировку «не лету» предусматривать не нужно.

Кроме того, мне кажется, само по себе изменение CGI тегов <META и добавление каких-то новых значение очень нежелательно. Например, мне необходимо было обеспечить наполнение выпадающего списка из словаря, оперативно подкачивая нужные значения при событии onFocus. Можно было воспользоваться свойством src объекта SCRIPT, но CGI вставлял дополнительные теги HTML и это не позволяло решить поставленную задачу таким способом. После устранения проблем с кодировкой эти проблемы будут автоматически сняты.

Мой девиз: больше свободы пользователям и минимум «откомпилированных решений»! :)

"...Единственное, что я не смогу сделать, это держать дистрибутив в двух вариантах. Поэтому каждому, кто захочет использовать НЕ UTF-8 предстоит утомительная работа по переводу фреймов - ини-файла - файла со строками ошибочных сообщений в нужную кодировку..." - зато вполне в ваших силах написать инструмент для перевода файлов из одной кодировки в другую. Уверен, что для Вас, Константин Олегович, это не сложно.

Как я понял, Константин Олегович писал здесь о будущем не только о Веб-ИРБИСа, но и "самого" ИРБИСа?
Можно отсюда ли сделать вывод, что будущий файл-серверный ИРБИС полностью утратит преемственность (совместимость) с CDS/ISIS? И хорошо ли это?
Но особенно грустно, что прекратит существование "32-й" GUI!!!

to К.Соколинский
1. Файл-серверная версия ИРБИС64 (если можно так сказать) уже существует в виде разновидности ИРБИС64ПТ, предназначенной для публикаций БД на CD (она же — в виде той демо-версии, которая с «КРЫМом» и «НТБ»). Насчет «больших сомнений в перспективности IRBIS 64». Его интерфейс мне по-прежнему кажется недоделанным. О «собственной СУБД» и новой структуре данных пока судить не берусь

2. Согласен, что если «32-е»семейство перестанет развиваться, большинство библиотек все равно будет использовать его устаревающие версии (и именно из-за интерфейса), а при появлении у них новых потребностей перейдёт не на 64, а на другие системы. Но только вряд ли на «Руслан» — ведь разработчики адресуют его только самым крупным и богатым библиотекам, причем обещают, что так будет и впредь. А тот факт, что «Нева» использует не реляционную СУБД, наводит на большие размышления… А вообще, хотя сейчас количество отечественных разработок САБ увеличивается, вскоре можно ожидать его уменьшения, в т. ч. за счет слияния коллективов разработчиков, и тогда проблема выбора (смены) системы потеряет смысл (впрочем, в ней всегда было мало смысла).

Офф топик: Если можете, прошу не обижаться, но упоминание «Руслана» напоминает пресловутый «ленинградский синдром». Вроде того, что, например, по результатам одного социологического исследования, лучший актер всех времен и народов — Басилашвили, крупнейший ученый — Лихачев и т. д. (а лучший в мире автомобиль, видимо, К-700:))))

P.S. Думаю, что для многих важнее контакт не с дилером, а непосредственно с ГПНТБ как с крупнейшим научным, учебным и т. д. центром и как с хорошими людьми…

Более удачное высказывание на эту тему:
«…самое главное это то, что система развивающаяся и ее разработчики охотно идут на контакты, прислушиваются к запросам своих потребителей». Березная Т.И., Рудзский Л.З. Опыт создания автоматизированной библиотечно-информационной системы в университетской библиотеке на базе системы ИРБИС // КРЫМ-2000