Например я могу из php кода обратиться обратиться к БД, получить данные и
сформировать из них динамическую таблицу. Причем этот php код будет заключен
в соответствующие теги и находится будет внутри html. То есть у меня будет
вначале и в конце html со статичный код, а середина будет формироваться
динамически. И никаких тут дополнительных обвязок не надо. ИМНО это очень
удобно. И такой же возможности я хочу и для SA-WEB, только вместо php у меня
будет скрипт на Watcom-SQL. И тогда мне не нужны будут ни какие скриповые
серверные расширения.
----------
То, что ты хочешь, по сути и является SQL. Веб-сервис, висящий на SA,
является выполняемым SQL скриптом. Куда там еще встраивать тег скрипта,
когда он и так скриптом является по умолчанию.?! Вот при выполнении хранимой
процедуры по порядку и выполняете все, что нужно, а в итоге возвращаете
клиенту сформированный таким образом html-данные. Ведь никто же не говорит,
что процедура должна возвращать только статичные страницы! Разумеется, все
написаное выше относится к RAW сервисам. Кстати, управлять сервисами
отличными от RAW невозможно, ни кодовую страницу, ни т.п. Поэтому мы
используем только RAW сервисы с собственными алгоритмами, позволяющими
указывать все что угодно, и отслеживать сессионность, и авторизацию и
прочее, как на настоящем ВЕБ-сервере.


Лично я не буду очень сильно удивлен, если в SA 12 http из сервера выкинут
на фиг. На мой взгляд это крутая, но совершенно бессмысленная
функциональность.
----------
А по мне, например, очень нужная вещь, позволяющая избавиться от не нужных
прослоек для интранет приложений. Мы используем данную функциональность
достаточно плотно.


Posted via ActualForum NNTP Server 1.4

Stalker4А ты что то можешь сказать по поводу третьего вопроса ?
Выбор кодировки системных ответов сервером, прямо скажем, не поддается логическому объяснению. Он не совпадает с кодировкой, установленной на сервере, и не совпадает с кодировкой БД. Но в целом, я не использую эти системные ответы (я так понял речь идет об ошибках 404,500 и т.п.). При необходимости, сам генерирую страницы с такими кодами, но ясное дело, что свои страницы я возвращаю с нужными тегами, заголовками и в нужной кодировке.
Кстати, в АСА есть параметр, указывающий на автоматическую перекодировку возвращаемых данных под клиента. Это касается и HTTP-запросов, и если браузер указывает, что он по-дефолту iso..., то и АСА возвращаемые данные перекодирует в это безобразие, что не есть хорошо. Читай мануалы.

По поводу хранения в зипах. А почему выбран именно такой формат хранения? Почему бы загружаемые данные в виде не запакованных док-файлов, не паковать COMPRESS'ом и хранить так, а при отдаче распаковывать DECOMPRESS'ом? Так и лицензии на зип не нарушите, и хранить будете компактнее. И еще один плюс будет: при отдаче такого потока по HTTP, можно его отдавать в gz формате, с минимальными доработками головы и хвоста в данных и в HTTP header'е.

P.S. При использовании gz для отдачи данных, необходимость в их распаковки отпадает. Это сделает сам браузер прозрачно для пользователя.

White OwlЯ ни разу не видел чтобы кто-то публиковал свои собственные библиотеки внешних функций. СУБД их делать позволяет, но лично у меня кроме как "для побаловаться" ни разу не возникало желания сделать такую dll.

Публиковать, конечно же, мало кто будет, ибо используется редко, но бывает очень необходимо. Причем в упомянутом мною случае как раз и пришлось мне использовать самописную внешнюю библиотеку. Расчитывать CRC на SQL скрипте получилось на порядки дольше, чем внешней функцией. А CRC нужно посчитать, чтобы получить gz из COMPRESS. Серединка у этих двух блобов одинаковая, только голова и хвост отличаются.


А что такого передавать данные на сервер не в запакованном виде? Клиент далеко и трафик ест? Ну так надо подумать, чтобы передавать по HTTP с использованием браузерного пакования. А если локалка, ну тогда вообще пофигу какие объемы. Если все же хотите сами паковать и отправлять на сервер упакованное, то можно сменить ZIP-библиотеку клиента, на GZip. Благо, она вроде бы свободная, есть в исходниках, и ее результат можно скормить в будущем функции DECOMPRESS на сервере...