Оценка востребованности релизов Clarion на февраль 2017 г.

[Developer]

Ага, попросите. SV все просьбы исполняет, причём моментально.
Давайте что-нибудь реальное просить. Например, создание нативного приложения для iOS.

Cоздание нативного приложения для iOS - это хорошо - а создание нативного приложения для Android будет более востребовано.

[Игорь Столяров]

Но обслуживается на одном компьютере

Согласен, TSPlus удобное решение, хотя конечно по возможностям не WinTerminal / Citrix.
Понятно, что установить можно на любой десктоп, но для полноценной работы, все-таки
нужен "сервер", который справится с десятком открытых сессий ...

[Игорь Столяров]

создание нативного приложения для Android будет более востребовано

Для меня это место величайшая загадка. Прикрутить сборку APP под Android - это простая бомба, которая сразу подняла
бы акции SV на порядок. Вместо этого они годами вошкаются то с .Net, то H5 ... Непонятно зачем и кому это нужно.

[finsoftrz]

Но обслуживается на одном компьютере

Согласен, TSPlus удобное решение, хотя конечно по возможностям не WinTerminal / Citrix.
Понятно, что установить можно на любой десктоп, но для полноценной работы, все-таки
нужен "сервер", который справится с десятком открытых сессий ...

В том и фишка, что в большинстве случаев под "сервер" можно взять практически любой бытовой компьютер. Будет тянуть 15-20 конкурентных пользователей без проблем (я, правда, такое видел на стандартном win terminal, не на tsplus). Особо не интересуюсь, что сейчас используют под сервера. Попадалась какая-то информация, что уже десятки гиг оперативки и десятки процессоров/ядер вполне на повестке дня. Даже не знаю, сколько там конкурентных пользователей можно запустить в терминале. Скорее всего, упремся не в производительность сервера, а в ограничения в 2ГБ в tps. Тогда уже придется поднимать первасив (к слову, писали, что связка первасива с терминалами очень крутое решение). Но в моем случае это не совсем целевая аудитория проекта будет...

[finsoftrz]

создание нативного приложения для Android будет более востребовано

Для меня это место величайшая загадка. Прикрутить сборку APP под Android - это простая бомба, которая сразу подняла
бы акции SV на порядок. Вместо этого они годами вошкаются то с .Net, то H5 ... Непонятно зачем и кому это нужно.

У меня была мысль сделать кодогенерацию для basic4android. Там ничего особо сложного нет, все хранится в текстовых файлах в utf8. Можно спокойно генерить, что нужно. Но так и не созрел. С одной стороны, приложения для андроида небольшие, для их создания вполне хватает и штатных возможностей basic4android. С другой, не восстребовано это оказалось у меня. Если клиентам реально надо что-то мобильное, можно и с виндой девайс взять. Так всем проще, стандартизация. Поэтому все наработки под андроид лежат и ждут момента, когда кому-нибудь это потребуется. Чем дальше, тем больше осознание того, что может не потребоваться никогда...

[kreator]

finsoftrz, терминальный сервер в принципе не для этого. Ну приладили для своих целей, и хорошо. Не может это быть конкуренцией SQL-серверу.
Кстати, у Винды есть сейчас т.н. RemoteApp. Сразу загружает удалённое приложение. Пользователю в этом случае меньше движений, вернее всего одно движение - нажать на иконку удалённого приложения.

[kreator]

Для меня это место величайшая загадка. Прикрутить сборку APP под Android - это простая бомба, которая сразу поднялабы акции SV на порядок. Вместо этого они годами вошкаются то с .Net, то H5 ... Непонятно зачем и кому это нужно.

Банально не хватает ресурсов. И насчёт бомбы тоже не факт. Дельфи заявляют о возможности генерации нативных приложений для Андроида и iOS. А вот какая отдача? Может и SV просчитало всё и не видит перспектив в этом. И я не согласен, что мобильные приложения должны быть простыми. Посмотрите, например, на "Яндекс Навигатор". Думаю до хрена человеко-часов затрат на разработку, да и ещё для нескольких систем.

[Игорь Столяров]

Посмотрите, например, на "Яндекс Навигатор".

Нет, ну безусловно, приложения собираемые на Clarion не претендуют на это ...
Но рынок различных мобильных информационных систем типа "меню -> список -> карточка" велик.
Непонятно еще и потому, что Clarion# практически был сделан Designer для мобильных платформ.

[finsoftrz]

finsoftrz, терминальный сервер в принципе не для этого. Ну приладили для своих целей, и хорошо. Не может это быть конкуренцией SQL-серверу.

Как уже писал, свое мнение не навязываю. Я работаю с терминалами с 2000 года, еще до возвращения к клариону. Когда разговаривали на эту тему с кларионистами году так в 2004-2005, их мало кто использовал. Некоторые тогда обратили внимание. Сейчас в зарубежных группах терминальные решения упоминаются регулярно, не намного реже, чем sql. И у нас уже немало людей практикуют эту схему работы.
Когда разговариваешь с людьми, которые когда-то перешли на sql, создается впечатление, что они не видели, как работают кларионовские приложения с tps на терминале. Все воспоминания и аргументы в сторону когда-то принятого решения о переходе на sql-сервера основаны на сравнении с файл-сервером.
Наша общая задача делать конкурентные приложения. Если в каких-то нишах удобно использовать sql сервера, почему нет. Но все не уперлось в них, а определяется принципами выживания и конкурентной борьбы. Не зря в вебе сейчас идет тренд ухода от sql в сторону noSQL. Ибо неважно, что пишут и рекламируют, а важна производительность. Аналогично, мне без разницы, кто как рекламирует решения на sql, я считаю деньги, и использование sql в моем случае совсем не ложится в картинку...

[Игорь Столяров]

кто как рекламирует решения на sql

Здесь наверно нужно посмотреть историю. Концепция SQL возникла лет 30-40 назад, когда предполагалось,
что "тонкие клиенты" будут выполнять запросы на сервере. Это пошло в разрез с развитием операционных
систем - они развиваются как рекламные платформы с возможностью воспроизведения мультимедийного
контента. В результате сегодня "офисные десктопы" - это достаточно мощные компьютеры, способные
тянуть несколько терминальных сессий, что вполне удобно для терминальных решений без SQL.

Здесь все верно. Если плюс к вышесказанному предположить, что реальная пропускная способность
сетей выйдет на 100 MByte / сек - действительно, не нужны будут никакие SQL, да и терминальные
решения тоже. Концепция NoSQL - победит за счет простоты разработки и поддержки, к чему видимо все и идет ...

[kreator]

Непонятно еще и потому, что Clarion# практически был сделан Designer для мобильных платформ.

Может ещё и поднимут тему. Но поскольку H5 сейчас в приоритете, то я подумал бы - как запустить собранное H5-приложение без браузера. Если сможем это сделать, то вот это будет реальная бомба - приложения, собранные в Кларионе, заработают на Андроиде и iOS. Проблема ещё, конечно, с Application Broker'ом.

Как уже писал, свое мнение не навязываю.

Похоже на это. Есть, например, одна проблема. Если Вам надо перебрать 2 миллиона записей по одной таблице, то что? Сколько нужно ждать при работе с tps?

[Игорь Столяров]

Сколько нужно ждать при работе с tps?

Думаю, что соизмеримо с получением выборки SELECT по тому же объему данных.
Разница в том, что в SQL можно получить только результат, а в TPS придется выгребать все.
Т.е. вопрос разницы производительности - это вопрос разницы скорости коммуникаций.
Пока еще она есть ...

[kreator]

Думаю, что соизмеримо с получением выборки SELECT по тому же объему данных.

Нет, не правда ваша. Несоизмеримо. Даже FB при таких объёмах уделает tps на два порядка. Не говорю о более продвинутых. И дело не в сети, речь о терминале.
У SQL-серверов есть ещё очень хорошая фича - планировщик запросов. Он показывает как (в каком порядке) перебираются данные. Представьте, что есть запрос по пяти таблицам, размер которых изначально не просчитывается, не простой в общем запрос. В файл-серверной системе Вы сразу заложили порядок обхода таблиц и оперативно его поменять не можете. А SQL-сервер ведёт анализ таблиц и меняет обход в зависимости от данных. Конечно, 100% гарантии оптимальности обхода нет, но фича работает хорошо.

[Игорь Столяров]

У SQL-серверов есть ещё очень хорошая фича - планировщик запросов

Я конечно, утрирую ... понятно, что SQL сервер это не просто ящик для файлов, он много чего делает.
Одно выполнение и откат транзакций на стороне сервера чего стоит ...

[kreator]

Конечно, я и говорю - возможности несоизмеримы. Я просто как-то циклюсь на быстродействии. Мне и SQL-ной порой не хватает. А бэкап? А шедулер? Все эти триггеры, хранимки. Удобно, эффективно.
По поводу развёртывания. FireBird. Ставиться на каждую станцию ODBC-драйвер, клиент FB (не знаю, правда, в чём его суть). Коннект прописывается настройках программы. С прямыми драйверами (Oracle/MS/SQLAny) вообще ничего не ставится.