Приветствую!
Я уже много тут писал про kalpa.cloud (раньше оно glan, vedga называлось). Но теперь предлагаю посмотреть что об этом говорит сам автор.

Вкратце для тех кто не в теме: Kalpa.Cloud это решение, базирующееся на Qt, позволяющее писать сетевые приложения со сверхтонким клиентом не задумываясь о том как оно будет работать в сетевом плане. Тоесть вы просто пишете Qt приложение с небольшими "отклонениями" (Имена классов называются с другой буквы, т.е. например QLabel->KLabel) и после сборки получаете готового демона, к которому можно подключаться универсальным клиентом.

Видео тут, 4ре части: http://www.youtube.com/view_play_list?p=D3CB4C151B1D60B1

Пишу тут, потому как хочется чтобы это посмотрели не только посетители специализированных форумов (С++, Веб).

S>Видео тут, 4ре части: http://www.youtube.com/view_play_list?p=D3CB4C151B1D60B1
S>Пишу тут, потому как хочется чтобы это посмотрели не только посетители специализированных форумов (С++, Веб).

На работе Ютуб закрыт, поэтому спрошу сразу: там затрагивается вопрос безопасности?

Приветствую, Mamut, вы писали:

M> На работе Ютуб закрыт, поэтому спрошу сразу: там затрагивается вопрос безопасности?
Немного. Там больше про эффективность.

M>> На работе Ютуб закрыт, поэтому спрошу сразу: там затрагивается вопрос безопасности?
S>Немного. Там больше про эффективность.

Жаль. Если про эффективность так же, как в блоге, то интереса это не представляет. Но дома посмотрю (если меня не соблазнит просмотр «теории большого взрыва» )

Приветствую, Mamut, вы писали:

M> Жаль. Если про эффективность так же, как в блоге, то интереса это не представляет. Но дома посмотрю (если меня не соблазнит просмотр «теории большого взрыва» )

Посмотришь все равно Ты воообще больше всех проявляешь интерес к этому делу тут.
И я не сомневаюсь что после просмотра ты опять заведешь старую шарманку.

Здравствуйте, Mamut, Вы писали:

M>...Но дома посмотрю (если меня не соблазнит просмотр «теории большого взрыва» )

А не скажешь, насколько верно следующее:

Очевидно, что решения на базе технологии HTML (веб-интерфейс) с использованием стандартного Веб-браузера не могут соответствовать этим требованиям.

здесь

Я не знаток WEB-а, но насколько я могу судить, там не используется голый HTML. В нашей конторе так довольно много софта работает.

M>>...Но дома посмотрю (если меня не соблазнит просмотр «теории большого взрыва» )

P>А не скажешь, насколько верно следующее:

P>

P>Очевидно, что решения на базе технологии HTML (веб-интерфейс) с использованием стандартного Веб-браузера не могут соответствовать этим требованиям.

P>здесь

Совсем не обязательно Интранеты тоже не на пустом месте появились


P>Я не знаток WEB-а, но насколько я могу судить, там не используется голый HTML. В нашей конторе так довольно много софта работает.

Ну, что там используется, давно известно завсегдатаям КСВ Веб в спорах про ведгу(калпу? глан?) появился только потому, что Шеридан не видит, что бразуер — точно такое же сетевое приложение, что и калпа(ведга?),а вслучае именно с ведгой(калпой) еще и работает почти по точно такому же протоклоу, только намного более грамотно реализованому

M>> Жаль. Если про эффективность так же, как в блоге, то интереса это не представляет. Но дома посмотрю (если меня не соблазнит просмотр «теории большого взрыва» )

S>Посмотришь все равно Ты воообще больше всех проявляешь интерес к этому делу тут.
S>И я не сомневаюсь что после просмотра ты опять заведешь старую шарманку.

А что ее заводить? Если автор до сих пор внятно ничего не может рассказать про безопасность, но про некую сферовакуумную эффективность рассказывает . Кстати, в вимдео хоть какие-то бенчмарки показаны? Или так все — вилами по воде?

Здравствуйте, Mamut, Вы писали:

M>Совсем не обязательно Интранеты тоже не на пустом месте появились

Вот и мне что-то подсказывает, что интранеты приводят к приличной экономии средств, при этом без ущерба для проекта.

M>Ну, что там используется, давно известно завсегдатаям КСВ

Я читаю КСВ в основном в минуты отдыха после починки какого-нибудь тяжелого бага, или если делаю что-нибудь монотонное, чтобы разрядиться. Что используется у нас — коллеги мне объяснили уже.

M>Веб в спорах про ведгу(калпу? глан?) появился только потому, что Шеридан не видит, что бразуер — точно такое же сетевое приложение, что и калпа(ведга?),а вслучае именно с ведгой(калпой) еще и работает почти по точно такому же протоклоу, только намного более грамотно реализованому

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

Здравствуйте, Mamut, Вы писали:

M>А что ее заводить? Если автор до сих пор внятно ничего не может рассказать про безопасность, но про некую сферовакуумную эффективность рассказывает . Кстати, в вимдео хоть какие-то бенчмарки показаны? Или так все — вилами по воде?

В прошлый раз, вроде, говорили о возможном SSL, чем не безопасность?

Здравствуйте, Privalov, Вы писали:

P>Здравствуйте, Mamut, Вы писали:

M>>Совсем не обязательно Интранеты тоже не на пустом месте появились

P>Вот и мне что-то подсказывает, что интранеты приводят к приличной экономии средств, при этом без ущерба для проекта.

А можно это расшифровать? Локальные сети приводящие к экономии средств...

M>>А что ее заводить? Если автор до сих пор внятно ничего не может рассказать про безопасность, но про некую сферовакуумную эффективность рассказывает . Кстати, в вимдео хоть какие-то бенчмарки показаны? Или так все — вилами по воде?

H>В прошлый раз, вроде, говорили о возможном SSL, чем не безопасность?

Ключевое слово было «возможный» Все, что нам известно о представлениях автора о безопасности здесь: http://oleg.kalpa.ru/2008_07_01_archive.html (мегашифрование Base64 + gzip).

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, Mamut, Вы писали:

M>>А что ее заводить? Если автор до сих пор внятно ничего не может рассказать про безопасность, но про некую сферовакуумную эффективность рассказывает . Кстати, в вимдео хоть какие-то бенчмарки показаны? Или так все — вилами по воде?

H>В прошлый раз, вроде, говорили о возможном SSL, чем не безопасность?

Тем что обеспечивает (и то с другом) защиту только от трети существующих информационных угроз, видимо

Здравствуйте, kochetkov.vladimir, Вы писали:

H>>В прошлый раз, вроде, говорили о возможном SSL, чем не безопасность?

KV>Тем что обеспечивает (и то с другом) защиту только от трети существующих информационных угроз, видимо

Забавно. Интересно, это Фрейд виноват, или это просто оговорка?

"с трудом", конечно же

Здравствуйте, Sheridan, Вы писали:

S>Тоесть вы просто пишете Qt приложение с небольшими "отклонениями"...
S>и после сборки получаете готового демона...

Когда в священном круге, дома,
Для зла исчезнет безопасность,
То мы опять, сначала, снова,
Изгоним демонов из дома.

(c) т/с "Зачарованные", первый сезон

Здравствуйте, hattab, Вы писали:

P>>Вот и мне что-то подсказывает, что интранеты приводят к приличной экономии средств, при этом без ущерба для проекта.

H>А можно это расшифровать? Локальные сети приводящие к экономии средств...

Да, совсем я что-то заработался. Наверное так: изобретать свою инфраструктуру обходится дороже использования готовой. К тому же интранет — это локальная сеть плюс еще что-то, нет?

Здравствуйте, kochetkov.vladimir, Вы писали:

M>>>А что ее заводить? Если автор до сих пор внятно ничего не может рассказать про безопасность, но про некую сферовакуумную эффективность рассказывает . Кстати, в вимдео хоть какие-то бенчмарки показаны? Или так все — вилами по воде?

H>>В прошлый раз, вроде, говорили о возможном SSL, чем не безопасность?

KV>Тем что обеспечивает (и то с другом) защиту только от трети существующих информационных угроз, видимо

А там и не предлагалось все проблемы им порешать, речь шла только о транспорте.

Здравствуйте, hattab, Вы писали:

KV>>Тем что обеспечивает (и то с другом) защиту только от трети существующих информационных угроз, видимо

H>А там и не предлагалось все проблемы им порешать, речь шла только о транспорте.

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

Здравствуйте, Mamut, Вы писали:

H>>В прошлый раз, вроде, говорили о возможном SSL, чем не безопасность?

M>Ключевое слово было «возможный» Все, что нам известно о представлениях автора о безопасности здесь: http://oleg.kalpa.ru/2008_07_01_archive.html (мегашифрование Base64 + gzip).

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

Здравствуйте, Privalov, Вы писали:

P>>>Вот и мне что-то подсказывает, что интранеты приводят к приличной экономии средств, при этом без ущерба для проекта.

H>>А можно это расшифровать? Локальные сети приводящие к экономии средств...

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

Инфраструктура... это открытый 80 и 443 порт на огнестенах чтоль?

P>К тому же интранет — это локальная сеть плюс еще что-то, нет?

Дословно -- Внутренняя сеть. Ничего более.

Здравствуйте, hattab, Вы писали:

H>Инфраструктура... это открытый 80 и 443 порт на огнестенах чтоль?

А всякие мелочи типа HTTP, FTP, etc не считается?

P>>К тому же интранет — это локальная сеть плюс еще что-то, нет?

H>Дословно -- Внутренняя сеть. Ничего более.

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

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>Тем что обеспечивает (и то с другом) защиту только от трети существующих информационных угроз, видимо

H>>А там и не предлагалось все проблемы им порешать, речь шла только о транспорте.

KV>Если "там" == "в КСВ", то речь шла о построении безопасных систем на базе ведги в целом. Кроме того, разве информация, которая передается по транспорту обладает какими-либо мистическими свойствами, обеспечивающими ей устойчивость к оставшимся угрозам?

Я говорю вот об этой

Автор: Sheridan
Дата: 24.07.08

теме. Общая безопасность там не обсуждалась. Речь шла о протоколе и его расширяемости (в частности об аутентификации и авторизации пользователей).

Здравствуйте, Privalov, Вы писали:

H>>Инфраструктура... это открытый 80 и 443 порт на огнестенах чтоль?

P>А всякие мелочи типа HTTP, FTP, etc не считается?

Ты о протоколах готовых или о серверах соответствующих? Ежели о протоколах, то не всегда они применимы (HTTP -- stateless, у Ведги statefull. stateless vs. statefull трогать не будем).

P>>>К тому же интранет — это локальная сеть плюс еще что-то, нет?

H>>Дословно -- Внутренняя сеть. Ничего более.

P>Я знаю перевод. Но даже если и так, никогда на дискетах обновления к настольным БД не получал/распространял?

Не могу воедино связать интранет и обновлениями на дискетах к настольным БД

Приветствую, Mamut, вы писали:

M> А что ее заводить? Если автор до сих пор внятно ничего не может рассказать про безопасность, но про некую сферовакуумную эффективность рассказывает . Кстати, в вимдео хоть какие-то бенчмарки показаны? Или так все — вилами по воде?
Бенчей нет, только выступление.
Безопасность же, друг мой, запросто усиливается сторонними средствами. На раз. Так что не начинай заново плакать.
Бенчмарки.... О чем может быть разговор, когда окошко с богатым интерфейсом весит около 20 килобайт при передаче. 20. Килобайт. Основной размер пакетов — десятки байт. Тебе еще бенчмарки? Опять??

Приветствую, hattab, вы писали:

h> M>Ключевое слово было «возможный» Все, что нам известно о представлениях автора о безопасности здесь: http://oleg.kalpa.ru/2008_07_01_archive.html (мегашифрование Base64 + gzip).
Слово vpn ничего такого не говорит? Или там к примеру проброс коннекта сквозь ssh?
Я к чему. Безопасность можно вдоль и поперек обеспечить сторонними средствами, причем это все делается просто.

h> Весьма сумбурное изложение. Как я и говорил в прошлый раз, автору следовало бы не ролики снимать, а толковый мануал написать для потенциальных разработчиков.
Ролик случайно получился. На форум просто пришел человек с камерой и снимал для себя. По моей просьбе слил видео и мне тоже.
Мануал там на 90% — это мануал который идет с qt. Остальные 10% есть в любом из примеров, которые лежат в репозитории. А пригождается реально лишь указываение на каком порту ждать подключений, да иногда несколько другое привязываение слотов к сигналам.

Здравствуйте, Sheridan, Вы писали:

S>Безопасность же, друг мой, запросто усиливается сторонними средствами. На раз.

*настороженно* я правильно понимаю, что после бани ты еще и экспертом по безопасности теперь стал?

Здравствуйте, hattab, Вы писали:

KV>>Если "там" == "в КСВ", то речь шла о построении безопасных систем на базе ведги в целом. Кроме того, разве информация, которая передается по транспорту обладает какими-либо мистическими свойствами, обеспечивающими ей устойчивость к оставшимся угрозам?

H>Я говорю вот об этой

Автор: Sheridan
Дата: 24.07.08

теме. Общая безопасность там не обсуждалась. Речь шла о протоколе и его расширяемости (в частности об аутентификации и авторизации пользователей).

Видимо мы говорим о разных темах. Но забавно, ибо именно в этой теме, DOOM вроде как доходчиво объяснил, почему SSL не очень удачный вариант:

А я бы напомнил, что аутентификация и авторизация это совсем не синонимы и вынести авторизацию в "отдельный протокол" не выйдет. А получить банально CN пользователя при аутентификации на сертификатах (я уж молчу, что такой способ аутентификации далеко не всегда приемлем) это все равно делать добавки в основное приложение.

M>> А что ее заводить? Если автор до сих пор внятно ничего не может рассказать про безопасность, но про некую сферовакуумную эффективность рассказывает . Кстати, в вимдео хоть какие-то бенчмарки показаны? Или так все — вилами по воде?
S>Бенчей нет, только выступление.
S>Безопасность же, друг мой, запросто усиливается сторонними средствами. На раз. Так что не начинай заново плакать.

Тебе Владимир Кочетков сто раз показал и рассказал, что это не так. Но, как известно, «невежество — это блаженство»

S>Бенчмарки.... О чем может быть разговор, когда окошко с богатым интерфейсом весит около 20 килобайт при передаче. 20. Килобайт. Основной размер пакетов — десятки байт. Тебе еще бенчмарки? Опять??

Повторю еще раз словами Синклера. То, что тебе очевидно, скорее всего неверно. Это было тебе показано и рассказано десятки раз в десятке топиков.

Кстати. Вопрос о том, как «среднестатиситический» сервер с ведгой(гланом) выдержит нагрузку хотя бы в 1000 клиентов так и остался нераскрытым. А ведь то тоже производительность. Ты ты же предпочитаешь не думать, когда что-то пишешь. Тебе лишь бы побрызгать слюной...

Здравствуйте, kochetkov.vladimir, Вы писали:

H>>Я говорю вот об этой

Автор: Sheridan
Дата: 24.07.08

теме. Общая безопасность там не обсуждалась. Речь шла о протоколе и его расширяемости (в частности об аутентификации и авторизации пользователей).

KV>Видимо мы говорим о разных темах. Но забавно, ибо именно в этой теме, DOOM вроде как доходчиво объяснил, почему SSL не очень удачный вариант:

KV>

KV>А я бы напомнил, что аутентификация и авторизация это совсем не синонимы и вынести авторизацию в "отдельный протокол" не выйдет. А получить банально CN пользователя при аутентификации на сертификатах (я уж молчу, что такой способ аутентификации далеко не всегда приемлем) это все равно делать добавки в основное приложение.

KV>

Ну, DOOM "объяснил" только свое предположение (я выделил) А вообще, SSL вполне может быть использован лишь для закрытия канала от снифера, а непосредственно аутентификацию можно обеспечивать тем самым challenge-response или подобным. Разумеется, поддержка этого дела должна быть в протоколе, но у автора в блоге об этом (challenge-response) и написано т.е. из прочитанного делается вывод, что оно реализуемо.

Здравствуйте, Sheridan, Вы писали:

h>> M>Ключевое слово было «возможный» Все, что нам известно о представлениях автора о безопасности здесь: http://oleg.kalpa.ru/2008_07_01_archive.html (мегашифрование Base64 + gzip).
S>Слово vpn ничего такого не говорит? Или там к примеру проброс коннекта сквозь ssh?
S>Я к чему. Безопасность можно вдоль и поперек обеспечить сторонними средствами, причем это все делается просто.

Отвечаешь Мамуту в сообщении ко мне... оригинально...

h>> Весьма сумбурное изложение. Как я и говорил в прошлый раз, автору следовало бы не ролики снимать, а толковый мануал написать для потенциальных разработчиков.
S>Ролик случайно получился. На форум просто пришел человек с камерой и снимал для себя. По моей просьбе слил видео и мне тоже.
S>Мануал там на 90% — это мануал который идет с qt. Остальные 10% есть в любом из примеров, которые лежат в репозитории. А пригождается реально лишь указываение на каком порту ждать подключений, да иногда несколько другое привязываение слотов к сигналам.

Зачем мануал по Qt, когда народ интересуется вещами типа масштабируемости, клиентских скриптов, обновлениями... Базовые в общем-то вещи... Хочется представление иметь прежде, чем начинать с этим знакомиться лично (т.е. чтоб было понятно, стоит оно того или нет).

Вот ты форум уже допиши и покажи всем, как оно работает в реальных условиях. Это будет лучше, чем сотня постингов во славу Ведги.

Приветствую, hattab, вы писали:

h> Вот ты форум уже допиши и покажи всем, как оно работает в реальных условиях. Это будет лучше, чем сотня постингов во славу Ведги.
Не могу, исходники пока закрыты.
Причина озвучена в видео.

Приветствую, kochetkov.vladimir, вы писали:

k> S>Безопасность же, друг мой, запросто усиливается сторонними средствами. На раз.

k> *настороженно* я правильно понимаю, что после бани ты еще и экспертом по безопасности теперь стал?

Нет, а в чем, собственно дело? Что я не так понимаю?

Приветствую, Mamut, вы писали:

M> S>Бенчей нет, только выступление.
M> S>Безопасность же, друг мой, запросто усиливается сторонними средствами. На раз. Так что не начинай заново плакать.
M> Тебе Владимир Кочетков сто раз показал и рассказал, что это не так. Но, как известно, «невежество — это блаженство»
Напомни-ка, а то чтото я не помню.

M> S>Бенчмарки.... О чем может быть разговор, когда окошко с богатым интерфейсом весит около 20 килобайт при передаче. 20. Килобайт. Основной размер пакетов — десятки байт. Тебе еще бенчмарки? Опять??

M> Повторю еще раз словами Синклера. То, что тебе очевидно, скорее всего неверно. Это было тебе показано и рассказано десятки раз в десятке топиков.
С частью я согласился, если ты помнишь.

M> Кстати. Вопрос о том, как «среднестатиситический» сервер с ведгой(гланом) выдержит нагрузку хотя бы в 1000 клиентов так и остался нераскрытым. А ведь то тоже производительность.
Выдерживает.

Здравствуйте, hattab, Вы писали:

H>Зачем мануал по Qt, когда народ интересуется вещами типа масштабируемости, клиентских скриптов, обновлениями... Базовые в общем-то вещи... Хочется представление иметь прежде, чем начинать с этим знакомиться лично (т.е. чтоб было понятно, стоит оно того или нет).

Тебе словосочетание "сверхтонкий клиент" ни о чем не говорит?
Вся(!) работа — на сервере. На клиенте только отбражение и ввод данных. В принципе автор хотел (не знаю как щас, может уже реализованно) прикрутить скрыпты там для того чтобы на клиенте выполнялись.
Что ты понимаешь под масштабируемостью?
Что в твоем понимании "обновление"?

Видео смотрел?

Здравствуйте, Sheridan, Вы писали:

H>>Зачем мануал по Qt, когда народ интересуется вещами типа масштабируемости, клиентских скриптов, обновлениями... Базовые в общем-то вещи... Хочется представление иметь прежде, чем начинать с этим знакомиться лично (т.е. чтоб было понятно, стоит оно того или нет).

S>Тебе словосочетание "сверхтонкий клиент" ни о чем не говорит?

Говорит... о том что он сверхтонкий.

S>Вся(!) работа — на сервере. На клиенте только отбражение и ввод данных. В принципе автор хотел (не знаю как щас, может уже реализованно) прикрутить скрыпты там для того чтобы на клиенте выполнялись.

S>Что ты понимаешь под масштабируемостью?

Масштабируемость. Особенно обрати внимание на слова:

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

S>Что в твоем понимании "обновление"?

Обновление бизнес-логики разумеется. Опишу кратко. Идет внедрение корпоративного софта с одновременной разработкой/доработкой. Большое количество юзеров уже работают с внедряемой системой. Но в бизнес-логику постоянно вносятся изменения (наращивается функционал, правятся баги). Бизнес-логика в Ведге это, как я понял, то самое серверное приложение. Вот и вопрос: как мне осуществить обновление (до нескольких раз в день) этого приложения, когда у меня пользователи работают (вносят данные, отчеты создают)? Попросить всех отключиться, перезалить серверный софт, оповестить всех отключившихся? Или есть механизм?

S>Видео смотрел?

GPRS

Приветствую, hattab, вы писали:

h> Масштабируемость. Особенно обрати внимание на слова:
h>

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

Автор вел в этом отношении работу. Не знаю как там сейчас честно говоря. Но могу сказать что к ресурсам оно не требовательно.

h> S>Что в твоем понимании "обновление"?
h> Обновление бизнес-логики разумеется. Опишу кратко. Идет внедрение корпоративного софта с одновременной разработкой/доработкой. Большое количество юзеров уже работают с внедряемой системой. Но в бизнес-логику постоянно вносятся изменения (наращивается функционал, правятся баги). Бизнес-логика в Ведге это, как я понял, то самое серверное приложение. Вот и вопрос: как мне осуществить обновление (до нескольких раз в день) этого приложения, когда у меня пользователи работают (вносят данные, отчеты создают)? Попросить всех отключиться, перезалить серверный софт, оповестить всех отключившихся? Или есть механизм?
На тот момент когда я писал под гланом, было "оповестить-выключить-переписать-запустить", но мы довольно долго обсуждали механизм обновления. Как оно сейчас — опятьже не знаю.

h> S>Видео смотрел?
h> GPRS
Жаль, там много интересного

Здравствуйте, hattab, Вы писали:

KV>>

KV>>А я бы напомнил, что аутентификация и авторизация это совсем не синонимы и вынести авторизацию в "отдельный протокол" не выйдет. А получить банально CN пользователя при аутентификации на сертификатах (я уж молчу, что такой способ аутентификации далеко не всегда приемлем) это все равно делать добавки в основное приложение.

KV>>

H>Ну, DOOM "объяснил" только свое предположение (я выделил) А вообще, SSL вполне может быть использован лишь для закрытия канала от снифера, а непосредственно аутентификацию можно обеспечивать тем самым challenge-response или подобным. Разумеется, поддержка этого дела должна быть в протоколе, но у автора в блоге об этом (challenge-response) и написано т.е. из прочитанного делается вывод, что оно реализуемо.

Я потерял нить твоих рассуждений.

Ты написал что обезопасить вегду можно посредством SSL. Я возразил, что далеко не всю безопасность можно им обеспечить. Ты возразил что речь шла о транспорте, в частности об авторизации и аутентификации. Я привел аргумент DOOM'а о слабой применимости SSL для этих задач в разрезе обсуждаемой темы. Ты возразил, что это частный случай и что SSL'ем можно закрыть только угрозу нарушения конфиденциальности информации в канале, а аутентификацию надо вводить в протокол (а что с авторизацией и аутентичностью, кстати?) и что автор якобы ее туда ввел.

Ок, пусть так, но к чему было тогда говорить об SSL?

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, Mamut, вы писали:

M>> S>Бенчей нет, только выступление.
M>> S>Безопасность же, друг мой, запросто усиливается сторонними средствами. На раз. Так что не начинай заново плакать.
M>> Тебе Владимир Кочетков сто раз показал и рассказал, что это не так. Но, как известно, «невежество — это блаженство»
S>Напомни-ка, а то чтото я не помню.

Не стоит утруждать Мамута поисками, говорил в КСВ — помню. Но мне не сложно повторить это еще раз здесь, в ФП. Просто дай мне часик-другой, чтобы разгрести рабочий хлам и собраться с мыслями

M>> Кстати. Вопрос о том, как «среднестатиситический» сервер с ведгой(гланом) выдержит нагрузку хотя бы в 1000 клиентов так и остался нераскрытым. А ведь то тоже производительность.
S>Выдерживает.

А 10 конкурирующих клиентов не выдержит по определению. Просто тупо не сможет их принять и все

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, kochetkov.vladimir, вы писали:

k>> S>Безопасность же, друг мой, запросто усиливается сторонними средствами. На раз.

k>> *настороженно* я правильно понимаю, что после бани ты еще и экспертом по безопасности теперь стал?

S>Нет, а в чем, собственно дело? Что я не так понимаю?

А это безотносительно ведги. Безопасность не реализовывается на раз хоть сторонними средствами, хоть потусторонними. Сие всегда есть компромис между производительностью / удобством использования и устойчивостью к тем или иным угрозам. Выбор приемлемой точки этого компромиса — дело не на раз и не на два. Поэтому, если что-то в безопасности конкретной системы было запросто усилено, это говорит либо о том, что ты только что сделал систему нефункционирующей, либо где-то чего-то не доглядел и она по-прежнему дырявая. Если ты конечно не эксперт уровня Шнайера, Ховарда и прочих. Поэтому и спросил

Приветствую, kochetkov.vladimir, вы писали:

k> А 10 конкурирующих клиентов не выдержит по определению. Просто тупо не сможет их принять и все

Что ты понимаешь под "конкурирующих"?

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, kochetkov.vladimir, вы писали:

k>> А 10 конкурирующих клиентов не выдержит по определению. Просто тупо не сможет их принять и все

S>Что ты понимаешь под "конкурирующих"?

10 одновременных запросов, пришедших на сервер в тот момент, когда он в состоянии обработать только один из них.

Приветствую, kochetkov.vladimir, вы писали:

k> S>Что ты понимаешь под "конкурирующих"?

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

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Я потерял нить твоих рассуждений.

KV>Ты написал что обезопасить вегду можно посредством SSL. Я возразил, что далеко не всю безопасность можно им обеспечить. Ты возразил что речь шла о транспорте, в частности об авторизации и аутентификации. Я привел аргумент DOOM'а о слабой применимости SSL для этих задач в разрезе обсуждаемой темы. Ты возразил, что это частный случай и что SSL'ем можно закрыть только угрозу нарушения конфиденциальности информации в канале, а аутентификацию надо вводить в протокол (а что с авторизацией и аутентичностью, кстати?) и что автор якобы ее туда ввел.

1. Авторизацию выполняет бизнес-логика, протокол тут не при чем.
2. Аутентичность чего?
3. По поводу "автор якобы ее туда ввел", я вообще-то не в курсе. У него в блоге так об этом написано, что не поймешь, сделано оно или это только его предложения к действию. У меня во всяком случае сложилось впечатление, что это все реализуемо без дополнительных переделок протокола, но как на самом деле

KV>Ок, пусть так, но к чему было тогда говорить об SSL?

SSL как готовый и широко используемый протокол, годный для закрытия канала + имеющий хорошую поддержку со стороны сетевых библиотек. Только и всего.

Здравствуйте, Sheridan, Вы писали:

h>> Масштабируемость. Особенно обрати внимание на слова:
h>>

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

S>Автор вел в этом отношении работу. Не знаю как там сейчас честно говоря.

Вот потому мануал и нужен.

S>Но могу сказать что к ресурсам оно не требовательно.

Потребление ресурсов к масштабированию отношения не имеет, масштабирование есть вопрос архитектуры.

h>> S>Что в твоем понимании "обновление"?
h>> Обновление бизнес-логики разумеется. Опишу кратко. Идет внедрение корпоративного софта с одновременной разработкой/доработкой. Большое количество юзеров уже работают с внедряемой системой. Но в бизнес-логику постоянно вносятся изменения (наращивается функционал, правятся баги). Бизнес-логика в Ведге это, как я понял, то самое серверное приложение. Вот и вопрос: как мне осуществить обновление (до нескольких раз в день) этого приложения, когда у меня пользователи работают (вносят данные, отчеты создают)? Попросить всех отключиться, перезалить серверный софт, оповестить всех отключившихся? Или есть механизм?
S>На тот момент когда я писал под гланом, было "оповестить-выключить-переписать-запустить", но мы довольно долго обсуждали механизм обновления. Как оно сейчас — опятьже не знаю.

Вот потому мануал и нужен.

Приветствую, hattab, вы писали:

h> Вот потому мануал и нужен.
Да согласен я что нужен, но дело в том что оно сейчас закрыто, и будет ли открыто — неизвестно. В видео есть разъяснение автором этого вопроса.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, Mamut, вы писали:

M>> S>Бенчей нет, только выступление.
M>> S>Безопасность же, друг мой, запросто усиливается сторонними средствами. На раз. Так что не начинай заново плакать.
M>> Тебе Владимир Кочетков сто раз показал и рассказал, что это не так. Но, как известно, «невежество — это блаженство»
S>Напомни-ка, а то чтото я не помню.

В общем, обобщенный ответ почему веб-приложения всегда будут безопаснее ведги и аналогов (при прочих равных) тут

Автор: kochetkov.vladimir
Дата: 27.11.09

. А про безопасность самой ведги готов поговорить, но хочу посмотреть ролик и почитать блог автора (тут мы с Мамутом в противофазе и смотреть видео я могу только на работе

Здравствуйте, Sheridan, Вы писали:
S>Я уже много тут писал про kalpa.cloud (раньше оно glan, vedga называлось). Но теперь предлагаю посмотреть что об этом говорит сам автор.
А что, собственно, предлагается в этой теме обсуждать? Технических подробностей, как это работает, ни на сайте, ни в презентации нет.

Приветствую, Mr.Cat, вы писали:

MC> А что, собственно, предлагается в этой теме обсуждать? Технических подробностей, как это работает, ни на сайте, ни в презентации нет.
Да я уже неоднократно и показывал и рассказывал, и давал пощупать...

Здравствуйте, Sheridan, Вы писали:
S>Да я уже неоднократно и показывал и рассказывал, и давал пощупать...
Ну это было давно. С того момента ничего не поменялось?

Приветствую, Mr.Cat, вы писали:

MC> Ну это было давно. С того момента ничего не поменялось?
Исходники закрыты. Но знаю что автор вроде работал над кластеризацией и над возможностью запускать серверную часть под виндами.

Здравствуйте, Sheridan, Вы писали:
S>Исходники закрыты.
И документации нет. Как-то не располагает к беседе.

Приветствую, Mr.Cat, вы писали:

MC> S>Исходники закрыты.
MC> И документации нет. Как-то не располагает к беседе.
Я с этим к сожалению ничего поделать не могу.

M>> S>Бенчей нет, только выступление.
M>> S>Безопасность же, друг мой, запросто усиливается сторонними средствами. На раз. Так что не начинай заново плакать.
M>> Тебе Владимир Кочетков сто раз показал и рассказал, что это не так. Но, как известно, «невежество — это блаженство»
S>Напомни-ка, а то чтото я не помню.

Не собираюсь. Все равно, как об стенку горох.


M>> S>Бенчмарки.... О чем может быть разговор, когда окошко с богатым интерфейсом весит около 20 килобайт при передаче. 20. Килобайт. Основной размер пакетов — десятки байт. Тебе еще бенчмарки? Опять??

M>> Повторю еще раз словами Синклера. То, что тебе очевидно, скорее всего неверно. Это было тебе показано и рассказано десятки раз в десятке топиков.
S>С частью я согласился, если ты помнишь.

Тогда что ты тут начинаеь рассказывать про 20 килобайт при передаче?


M>> Кстати. Вопрос о том, как «среднестатиситический» сервер с ведгой(гланом) выдержит нагрузку хотя бы в 1000 клиентов так и остался нераскрытым. А ведь то тоже производительность.
S>Выдерживает.

Результаты бенчмарков в студию.

MC>> S>Исходники закрыты.

Как я и говорил, автор раскрыл исходники только, чтобы потешить ЧСВ


MC>> И документации нет. Как-то не располагает к беседе.
S>Я с этим к сожалению ничего поделать не могу.

Тогда что мы осбуждаем? Особенности поведения сферических конец в вакууме? Ты эта, напомни автору следующее:

Потому, основная цель состоит не в том, чтобы популяризировать инструмент-Vedga среди враждебно настроенных HTML-сетевиков, но чтобы активно выступить с набором прикладных решений. Чем и занимаеюсь.

Пока этого не будет, калпа(ведга?) — унылое, никому не нужное гуано. Это справедливо для абсолютно любого проекта, пока не будет доказано обратное.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, kochetkov.vladimir, вы писали:

k>> S>Что ты понимаешь под "конкурирующих"?

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

Не получится создать такую ситуацию или не получится обработать все 10 запросов?

h>> Вот потому мануал и нужен.
S>Да согласен я что нужен, но дело в том что оно сейчас закрыто, и будет ли открыто — неизвестно. В видео есть разъяснение автором этого вопроса.

А можно озвучить здесь? А то я так и не посмотрел видео

H>Ну, DOOM "объяснил" только свое предположение (я выделил) А вообще, SSL вполне может быть использован лишь для закрытия канала от снифера, а непосредственно аутентификацию можно обеспечивать тем самым challenge-response или подобным. Разумеется, поддержка этого дела должна быть в протоколе, но у автора в блоге об этом (challenge-response) и написано т.е. из прочитанного делается вывод, что оно реализуемо.

Challenge-response в ведге нереализуем без смены всех клиентов. Особенности-с

Здравствуйте, Mamut, Вы писали:

H>>Ну, DOOM "объяснил" только свое предположение (я выделил) А вообще, SSL вполне может быть использован лишь для закрытия канала от снифера, а непосредственно аутентификацию можно обеспечивать тем самым challenge-response или подобным. Разумеется, поддержка этого дела должна быть в протоколе, но у автора в блоге об этом (challenge-response) и написано т.е. из прочитанного делается вывод, что оно реализуемо.

M>Challenge-response в ведге нереализуем без смены всех клиентов. Особенности-с

Думается мне, что на данном этапе развития ведги это проблем не составляет

H>>>Ну, DOOM "объяснил" только свое предположение (я выделил) А вообще, SSL вполне может быть использован лишь для закрытия канала от снифера, а непосредственно аутентификацию можно обеспечивать тем самым challenge-response или подобным. Разумеется, поддержка этого дела должна быть в протоколе, но у автора в блоге об этом (challenge-response) и написано т.е. из прочитанного делается вывод, что оно реализуемо.

M>>Challenge-response в ведге нереализуем без смены всех клиентов. Особенности-с

H>Думается мне, что на данном этапе развития ведги это проблем не составляет

Но как только количество инсталляций станет больше нуля, уже представит

Здравствуйте, Mamut, Вы писали:

M>>>Challenge-response в ведге нереализуем без смены всех клиентов. Особенности-с

H>>Думается мне, что на данном этапе развития ведги это проблем не составляет

M>Но как только количество инсталляций станет больше нуля, уже представит

Автор наверняка задумывался об этом

Здравствуйте, Sheridan, Вы писали:

S>Жаль, там много интересного

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

а теперь покритикуем презентера.

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

терминалки:
— порадовала ирония автора на тему того, что в терминалках неэфективно используется сеть. ибо на каждый чих идет запрос по сети. и это говорит человек, у которого драг н дроп реализован точно так же?

веб:
— даже не знаю, чего сказать — просто фэерычно. автор с матчастью не знаком.

в общем, смотрел вчера, уже всех подробностей не помню. поправьте, кто смотрел.

а теперь уже про ведгу:
— вопрос безопасности не раскрыт вообще. окромя восторгов о том, что если украдут ноутбук, то все данные остануться на сервере.
— до сих пор нет никаких возможностей индексации и адресации контента. напомню, мы говорим о технологии, позволяющей в перспективе создавать масштабные сетевые ресурсы, содержащие многочисленную информацию. а потому, как нам рассказывал шеридан о своем форуме, сказать человеку, путь к конкретному топику, чтобы человек сам открыл — не получиться. нужно иметь возможность это дело индексировать и должно присутствовать адрресабилити.
— на каждый чих идут запросы к ведга серверу. UI рисуется на серваке и отдается клиенту. господа шеридан и олег кальпа, вы поймите одно. гордится тем, что гонятеся всего 15-20 кб и это здорово — это пол-дела. есть такая вещь, как латентность сети. и способность сервера обрабатывать такое к-во да часто еще и конкурирущих запросов. вот начинаете вы тянуть картинку, пошли запросы на сервер, сеть лаганула, бумс. и все остановилось. нельзя, господа, делать вид, что network state(ширина канала и даже растояние до сервера) не имеют значения. будут иметь. и как-то это прийдется обрабатывать. поланируете вводить клиенские скрипты? вперед. но не кажеться ли вам, что вы изобретаете уже что-то существующее.
— протокол. вопрос фаерволов открыт.

M>>>>Challenge-response в ведге нереализуем без смены всех клиентов. Особенности-с
H>>>Думается мне, что на данном этапе развития ведги это проблем не составляет
M>>Но как только количество инсталляций станет больше нуля, уже представит
H>Автор наверняка задумывался об этом

Что-то я сильно сомневаюсь

Здравствуйте, a_kutovets, Вы писали:

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

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

_>а потому, как нам рассказывал шеридан о своем форуме, сказать человеку, путь к конкретному топику, чтобы человек сам открыл — не получиться. нужно иметь возможность это дело индексировать и должно присутствовать адрресабилити.

Адресуемость это просто дополнительная, иногда полезная, фича, которая руками прикручивается даже к толстому клиенту

_>— на каждый чих идут запросы к ведга серверу. UI рисуется на серваке и отдается клиенту.

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

_>- протокол. вопрос фаерволов открыт.

В интранете не весть какая проблема

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, a_kutovets, Вы писали:

_>>а теперь уже про ведгу:
_>>- до сих пор нет никаких возможностей индексации и адресации контента. напомню, мы говорим о технологии, позволяющей в перспективе создавать масштабные сетевые ресурсы, содержащие многочисленную информацию.
H>Мне кажется, что с позиционированием тут промашка Ведга это скорее уровень корпоративного софта, без претензий на глобальность. И таки как замена HTML-мордовых приложений выглядит интересно, где-то на уровне толстых клиентов
Со сравнению с современным технологиями создания RIA этот Kalpa — лажа полнейшая.
Кроме того соременный корпоративный софт все чаще доступен в интернете.

_>>а потому, как нам рассказывал шеридан о своем форуме, сказать человеку, путь к конкретному топику, чтобы человек сам открыл — не получиться. нужно иметь возможность это дело индексировать и должно присутствовать адрресабилити.
H>Адресуемость это просто дополнительная, иногда полезная, фича, которая руками прикручивается даже к толстому клиенту

К готовому приложению с определенной архитектурой полную адресуемость прикрутить нереально.

_>>— на каждый чих идут запросы к ведга серверу. UI рисуется на серваке и отдается клиенту.
H>GUI как раз таки рисуется на клиенте Сервер отдает описание, клиент рисует. Тут проблема будет в том, что при использовании дополнительных гуй-элементов на стороне сервера, Ведга-браузер придется обновлять (если конечно не предусмотрен механизм подключаемых модулей ).

Тут имеется ввиду что для повяления нового поля требуется запрос на сервер.
Вообще проблема в отсуствии клиентского скриптинга. Вроде как его собирались прикручивать, но до уровня современных js-движков в браузерах он в жизни не дотянет.

Приветствую, Mamut, вы писали:

M> А можно озвучить здесь? А то я так и не посмотрел видео

Я щас напишу, ты выльешь тонну дерьма, я начну спорить. Не хочу. Смотри видео.

Приветствую, Mamut, вы писали:

M> H>Автор наверняка задумывался об этом
M> Что-то я сильно сомневаюсь
Мамут, считать всех кроме себя придурками — как минимум некультурно.

Приветствую, kochetkov.vladimir, вы писали:

k> k>> 10 одновременных запросов, пришедших на сервер в тот момент, когда он в состоянии обработать только один из них.
k> S>Не получится емнип. Просто потому как там под каждого клиента свой поток.
k> Не получится создать такую ситуацию или не получится обработать все 10 запросов?
Ситуацию не получится. Разве что программер будет криворук...

Приветствую, Mamut, вы писали:

M> Результаты бенчмарков в студию.
Приводил уже.

Приветствую, Mamut, вы писали:

M> Пока этого не будет, калпа(ведга?) — унылое, никому не нужное гуано. Это справедливо для абсолютно любого проекта, пока не будет доказано обратное.

Мамут. Твой софт — дерьмо. Я его правда не видет и ине трогал. Но он — дерьмо. Пока не докажешь обратное.
Приятно?
Вот приблизительно это ты и заявляешь со всей прямотой.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, kochetkov.vladimir, вы писали:

k>> k>> 10 одновременных запросов, пришедших на сервер в тот момент, когда он в состоянии обработать только один из них.
k>> S>Не получится емнип. Просто потому как там под каждого клиента свой поток.
k>> Не получится создать такую ситуацию или не получится обработать все 10 запросов?
S>Ситуацию не получится. Разве что программер будет криворук...

Так, попробуем зайти с другого конца. Ведга держит открытый сокет на каждого клиента?

Здравствуйте, gandjustas, Вы писали:

H>>Мне кажется, что с позиционированием тут промашка Ведга это скорее уровень корпоративного софта, без претензий на глобальность. И таки как замена HTML-мордовых приложений выглядит интересно, где-то на уровне толстых клиентов
G>Со сравнению с современным технологиями создания RIA этот Kalpa — лажа полнейшая.

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

G>Кроме того соременный корпоративный софт все чаще доступен в интернете.

Я не в курсе зачем, скажем, диспетчерам транспортного цеха нужен доступ к софту через инет, но пусть так VPN?

_>>>а потому, как нам рассказывал шеридан о своем форуме, сказать человеку, путь к конкретному топику, чтобы человек сам открыл — не получиться. нужно иметь возможность это дело индексировать и должно присутствовать адрресабилити.
H>>Адресуемость это просто дополнительная, иногда полезная, фича, которая руками прикручивается даже к толстому клиенту

G>К готовому приложению с определенной архитектурой полную адресуемость прикрутить нереально.

А полную и не нужно, достоточно необходимую (если вообще есть такая необходимость).

M>> А можно озвучить здесь? А то я так и не посмотрел видео

S>Я щас напишу, ты выльешь тонну дерьма, я начну спорить. Не хочу. Смотри видео.

Не вылью Мне интересно, в чем причина?

ЗЫ. Если я выливаю тонны дерьма, то я аргументирую каждый килограмм из этой тонны.

M>> H>Автор наверняка задумывался об этом
M>> Что-то я сильно сомневаюсь
S>Мамут, считать всех кроме себя придурками — как минимум некультурно.

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

M>> Пока этого не будет, калпа(ведга?) — унылое, никому не нужное гуано. Это справедливо для абсолютно любого проекта, пока не будет доказано обратное.

S>Мамут. Твой софт — дерьмо. Я его правда не видет и ине трогал. Но он — дерьмо. Пока не докажешь обратное.
S>Приятно?
S>Вот приблизительно это ты и заявляешь со всей прямотой.

Так и есть. Понимаешь, именно так и работает индустрия. И я к этому спокойно отношусь, в отличие от. Ценность и полезность каких-либо решений надо доказывать. Причем доказывать убедительно.

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, gandjustas, Вы писали:

H>>>Мне кажется, что с позиционированием тут промашка Ведга это скорее уровень корпоративного софта, без претензий на глобальность. И таки как замена HTML-мордовых приложений выглядит интересно, где-то на уровне толстых клиентов
G>>Со сравнению с современным технологиями создания RIA этот Kalpa — лажа полнейшая.

H>Думается мне, что человеку писавшему десктопный софт будет сильно проще освоить именно Ведгу, нежели веб-программирование. И это неплохой плюс.
Человеку, писавшему десктопный софт еще много чего надо будет освоить при переходе в расределенную среду, при этом современные средства для RIA приложений не потребуют особо глубоких знаний именно веба.

G>>Кроме того соременный корпоративный софт все чаще доступен в интернете.
H>Я не в курсе зачем, скажем, диспетчерам транспортного цеха нужен доступ к софту через инет, но пусть так VPN?
Диспетчерам может и не понадобится, а вот менеджерам и директору доступ вполне может понадобиться.

_>>>>а потому, как нам рассказывал шеридан о своем форуме, сказать человеку, путь к конкретному топику, чтобы человек сам открыл — не получиться. нужно иметь возможность это дело индексировать и должно присутствовать адрресабилити.
H>>>Адресуемость это просто дополнительная, иногда полезная, фича, которая руками прикручивается даже к толстому клиенту

G>>К готовому приложению с определенной архитектурой полную адресуемость прикрутить нереально.

H>А полную и не нужно, достоточно необходимую (если вообще есть такая необходимость).

В большинстве приложений нужна адресация, причем чем полнее, тем лучше. Даже в ворде есть гиперпереходы, хотя там "рабочая область" (предментой областью это сложно назвать) ни разу не структурированная.

Здравствуйте, gandjustas, Вы писали:

H>>Думается мне, что человеку писавшему десктопный софт будет сильно проще освоить именно Ведгу, нежели веб-программирование. И это неплохой плюс.
G>Человеку, писавшему десктопный софт еще много чего надо будет освоить при переходе в расределенную среду, при этом современные средства для RIA приложений не потребуют особо глубоких знаний именно веба.

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

G>>>Кроме того соременный корпоративный софт все чаще доступен в интернете.
H>>Я не в курсе зачем, скажем, диспетчерам транспортного цеха нужен доступ к софту через инет, но пусть так VPN?
G>Диспетчерам может и не понадобится, а вот менеджерам и директору доступ вполне может понадобиться.

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

_>>>>>а потому, как нам рассказывал шеридан о своем форуме, сказать человеку, путь к конкретному топику, чтобы человек сам открыл — не получиться. нужно иметь возможность это дело индексировать и должно присутствовать адрресабилити.
H>>>>Адресуемость это просто дополнительная, иногда полезная, фича, которая руками прикручивается даже к толстому клиенту

G>В большинстве приложений нужна адресация, причем чем полнее, тем лучше. Даже в ворде есть гиперпереходы, хотя там "рабочая область" (предментой областью это сложно назвать) ни разу не структурированная.

Если при разработке данное требование озвучено не вижу проблем для реализации

Здравствуйте, hattab, Вы писали:

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

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

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

но опять же. в рамках интранета я на счет ведги мало что имею против. как замену толстым клиентам. здесь, конечно, можно вспомнить и о другом минусе — C++/Qt.

H>Я не в курсе зачем, скажем, диспетчерам транспортного цеха нужен доступ к софту через инет, но пусть так VPN?

VPN не панацея ни разу. как показала практика, гораздо удобнее работать с ресурсом висящим наружу.

H>А полную и не нужно, достоточно необходимую (если вообще есть такая необходимость).

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

Здравствуйте, a_kutovets, Вы писали:

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

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

_>но. есть еще веб интранет. на данный момент существует много рапид инструментов для веб разработки. да, можно долго ругать теже asp.net веб формы, но с их помощью интранет приложения делаются реально одной левой.

Далеко не всем юзерам нравится HTML-гуй. Лично мне очень не нравится. До сих пор не использую ни одного подобного приложения (кроме сайтов ес-но).

_>но опять же. в рамках интранета я на счет ведги мало что имею против. как замену толстым клиентам. здесь, конечно, можно вспомнить и о другом минусе — C++/Qt.

Для человека имеющего опыт в C++/Qt вряд ли это минус

H>>Я не в курсе зачем, скажем, диспетчерам транспортного цеха нужен доступ к софту через инет, но пусть так VPN?

_>VPN не панацея ни разу. как показала практика, гораздо удобнее работать с ресурсом висящим наружу.

Так никто и не говорит о панацее, просто одна из возможностей.

H>>А полную и не нужно, достоточно необходимую (если вообще есть такая необходимость).

_>вопрос гибкого адресабилити наиболее остро стоит в зависимости от объемов информации. также и индексировании. чем больше информации, тем больше потребность в гибком к нее доступе. те интранет приложения, которые я делал и с которыми я знаком, как раз этого остро требовали.

Я о требованиях адресуемости вообще только на РСДН прочитал К тому же, как я уже писал, нет ровным счетом ни каких проблем для ее реализации в любом приложении.

Приветствую, Mamut, вы писали:

M> S>Мамут. Твой софт — дерьмо. Я его правда не видет и ине трогал. Но он — дерьмо. Пока не докажешь обратное.
M> S>Приятно?
M> S>Вот приблизительно это ты и заявляешь со всей прямотой.

M> Так и есть. Понимаешь, именно так и работает индустрия. И я к этому спокойно отношусь, в отличие от. Ценность и полезность каких-либо решений надо доказывать. Причем доказывать убедительно.

Мамут, мы нихера не конкуренты, так что меня можно и не обливать дерьмом.

Здравствуйте, hattab, Вы писали:

H>Я о требованиях адресуемости вообще только на РСДН прочитал К тому же, как я уже писал, нет ровным счетом ни каких проблем для ее реализации в любом приложении.

Ну это ты неправду пишешь.
Возьми 1С и добавь туда адресуемость.

Здравствуйте, hattab, Вы писали:

H>Терминалки довольно требовательны к серверам и каналам. Мы в свое время, после нескольких экспериментов, от них отказались и сделали обычную трехзвенку, которая к слову прекрасно работала на каналах в 64kbps всего. Исходя из того что пишет автор Ведги, по трафику там расход будет небольшой, хотя конечно для выводов нужно что-то более конкретное кроме слов

согласен. терминалки прожорливые. здесь ведга в выиграше. но совершенно непонятно, как она себя ведет в малтиюзер режиме. бенчмарков до сих пор нет. только песни про 15-20 кб на запрос. а сколько запросов в секунду отбработать может ведга-сервер — а черт его знает)))

H>Далеко не всем юзерам нравится HTML-гуй. Лично мне очень не нравится. До сих пор не использую ни одного подобного приложения (кроме сайтов ес-но).

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

твои личные предпочтения важны для паблик ресурсов, где, как мы уже выяснили, ведге мало что светит.

H>Для человека имеющего опыт в C++/Qt вряд ли это минус

ну, тогда популярность ее остановится на людях, которые знают C++/Qt или работают/-ли с ними в последнее время. я, например, точно не хочу снова на плюсах писать подобные приложения.

также, а что там с Qt лицензированием? я как-то не в курсе последних изменений там.

H>Я о требованиях адресуемости вообще только на РСДН прочитал К тому же, как я уже писал, нет ровным счетом ни каких проблем для ее реализации в любом приложении.

вот тогда и начнутся костыли. да если еще и захотим клиента поменять. а это уже на n юзер машинах.

Приветствую, Mamut, вы писали:

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

Приветствую, gandjustas, вы писали:

g> Тут имеется ввиду что для повяления нового поля требуется запрос на сервер.
Для появления нового поля никаких запросов не нужно. Сервер сам отправит все что надо когда возникнет необходимость.
Напоминаю что в случае ведга-приложения контекст клиента сервер никогда не теряет.

g> Вообще проблема в отсуствии клиентского скриптинга. Вроде как его собирались прикручивать, но до уровня современных js-движков в браузерах он в жизни не дотянет.
Чем меньше выполняется на клиенте — тем меньше проблем.

Приветствую, hattab, вы писали:

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

Именно так.

Приветствую, kochetkov.vladimir, вы писали:

k> Так, попробуем зайти с другого конца. Ведга держит открытый сокет на каждого клиента?
Ведга вообще держит отдельный поток (или форк. Раньше были форки, но автор говорил что переводит нав потоки) на каждого клиента.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, gandjustas, вы писали:

g>> Тут имеется ввиду что для повяления нового поля требуется запрос на сервер.
S>Для появления нового поля никаких запросов не нужно. Сервер сам отправит все что надо когда возникнет необходимость.
И с чего поле само появится? Вероятнее всего от какого-то действия пользователя, а как сервер узнает о действии пользователя? Правильно — пойдет запрос на сервер. При этом такие раунд-трипы совершенно не являются обязательными.

S>Напоминаю что в случае ведга-приложения контекст клиента сервер никогда не теряет.
То есть держит открытое соединение, что очень плохо в плане расходования ресурсов.

g>> Вообще проблема в отсуствии клиентского скриптинга. Вроде как его собирались прикручивать, но до уровня современных js-движков в браузерах он в жизни не дотянет.
S>Чем меньше выполняется на клиенте — тем меньше проблем.
Напиши сразу что это для тебя очевидно, чтобы все сразу поняли что ты неправ и мне не пришлось бы это объяснять.

Здравствуйте, Sheridan, Вы писали:
S>Напоминаю что в случае ведга-приложения контекст клиента сервер никогда не теряет.
А если клиент отсоединится? У меня вот, бывает, роутер заглючит, вайфай нечаянно выключу или еще чего — куда контекст денется?

PS: Я, собственно, про эту ситуацию и хотел сказать. "Писать клиент-серверное приложение как обычное десктопное" — идея хороша. Но рсдн хочет знать о технологических решениях, которые лежат, в основе всего этого. То, что мы видели когда-то давно, в первых ведга-тредах — это, я так понимаю, просто proof of concept (или нет?) — сейчас же автор говорит, что у него есть продавабельное решение.

Здравствуйте, gandjustas, Вы писали:

H>>Я о требованиях адресуемости вообще только на РСДН прочитал К тому же, как я уже писал, нет ровным счетом ни каких проблем для ее реализации в любом приложении.

G>Ну это ты неправду пишешь.
G>Возьми 1С и добавь туда адресуемость.

Ты невнимательно читал:

Если при разработке данное требование озвучено не вижу проблем для реализации

Более того, учитывая программируемость 1С, у меня есть основания предполагать, что это таки возможно.

Здравствуйте, a_kutovets, Вы писали:

H>>Далеко не всем юзерам нравится HTML-гуй. Лично мне очень не нравится. До сих пор не использую ни одного подобного приложения (кроме сайтов ес-но).

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

Вопрос отношения очень субъективный, посему просто пример из жизни Одна контора, с большим транспортным цехом, хотела внедрять новый софт для работы с путевками, учета ГСМ и пр. Обломилась на этапе пробного внедрения т.к. диспетчеры отказались использовать Windows GUI (до этого использовался софт с мордой на TurboVision. 1998 год). Просто засыпали внедренцев претензиями и все.

H>>Для человека имеющего опыт в C++/Qt вряд ли это минус

_>ну, тогда популярность ее остановится на людях, которые знают C++/Qt или работают/-ли с ними в последнее время. я, например, точно не хочу снова на плюсах писать подобные приложения.

Но ведь есть и те кто хочет писать на плюсах

_>также, а что там с Qt лицензированием? я как-то не в курсе последних изменений там.

Вроде бесплатно все

H>>Я о требованиях адресуемости вообще только на РСДН прочитал К тому же, как я уже писал, нет ровным счетом ни каких проблем для ее реализации в любом приложении.

_>вот тогда и начнутся костыли. да если еще и захотим клиента поменять. а это уже на n юзер машинах.

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

Здравствуйте, Sheridan, Вы писали:

h>> Мне кажется, что с позиционированием тут промашка Ведга это скорее уровень корпоративного софта, без претензий на глобальность. И таки как замена HTML-мордовых приложений выглядит интересно, где-то на уровне толстых клиентов
S>Именно так.
а тогда какого чёрта мы в КСВ обсуждаем цитату автора о необходимости общения "традиционного" веб-приложения с прокси-сервером?

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, gandjustas, Вы писали:

H>>>Я о требованиях адресуемости вообще только на РСДН прочитал К тому же, как я уже писал, нет ровным счетом ни каких проблем для ее реализации в любом приложении.

G>>Ну это ты неправду пишешь.
G>>Возьми 1С и добавь туда адресуемость.

H>Ты невнимательно читал:
H>

Если при разработке данное требование озвучено не вижу проблем для реализации

H>Более того, учитывая программируемость 1С, у меня есть основания предполагать, что это таки возможно.

Ну так сделай. Или хотябы оцентку трудозатрат приведи.

Это только кажется что так просто все. Если изначально в архитектуру не заложена адресуемость, то прикрутить её проблематично.

Ждать что заказчик тебе скажет про адресуемость не стоит, зачастую это вопрос юзабилити, а не функциональных требований.

Приветствую, gandjustas, вы писали:

g> И с чего поле само появится? Вероятнее всего от какого-то действия пользователя, а как сервер узнает о действии пользователя? Правильно — пойдет запрос на сервер. При этом такие раунд-трипы совершенно не являются обязательными.
Если появление поля — результат нажатия на кнопку пользователем, то на сервер полетит сигнал "кнопка такаято нажата", сервер в ответ плюнет описанием поля итд.
Если поле появляется к примеру по таймеру, то по таймауту сервер сам плюнет нужным описанием.

g> S>Напоминаю что в случае ведга-приложения контекст клиента сервер никогда не теряет.
g> То есть держит открытое соединение, что очень плохо в плане расходования ресурсов.
Поподробнее.

g> S>Чем меньше выполняется на клиенте — тем меньше проблем.
g> Напиши сразу что это для тебя очевидно, чтобы все сразу поняли что ты неправ и мне не пришлось бы это объяснять.
Нет уж, объясни. И не надо говорить за других.

Приветствую, Mr.Cat, вы писали:

MC> А если клиент отсоединится? У меня вот, бывает, роутер заглючит, вайфай нечаянно выключу или еще чего — куда контекст денется?
Чудес не бывает, хотя в этом направлении Олег тоже работал. Я не знаю как сейчас, но когда я писал под ведгу — обрыв связи был критичен. Впрочем он критичен практически везде.

MC> PS: Я, собственно, про эту ситуацию и хотел сказать. "Писать клиент-серверное приложение как обычное десктопное" — идея хороша. Но рсдн хочет знать о технологических решениях, которые лежат, в основе всего этого. То, что мы видели когда-то давно, в первых ведга-тредах — это, я так понимаю, просто proof of concept (или нет?) — сейчас же автор говорит, что у него есть продавабельное решение.
Я знаю лишь что какието изменения были.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>В общем, обобщенный ответ почему веб-приложения всегда будут безопаснее ведги и аналогов (при прочих равных) тут

Автор: kochetkov.vladimir
Дата: 27.11.09

. А про безопасность самой ведги готов поговорить, но хочу посмотреть ролик и почитать блог автора (тут мы с Мамутом в противофазе и смотреть видео я могу только на работе

Посмотрел ролик Небольшой офф: пафосность и желчь докладчика может и воспринимались бы нормально, если бы у него имелись хотя бы элементарные навыки проведения презентаций и осведомленность по части тех технологий, которые он вызвался критиковать. Диалог с аудиторией отсутствует, никаких попыток привлечь внимание отвлекшихся слушателей не предпринимается, хоть какие-то эмоции и попытки воздействия на аудиторию наблюдаются только во время критики уже существующих технологий. Общее впечатление, что ведущему на аудиторию плевать и что во время презентации просиходит что-то из разряда "только дайте мне трибуну". На фоне откровенного неуважения аудитории к нему (постоянный гул, разговоры, в т.ч. и оператора, осуществлявшего съемку, звонки мобильных, перебивание докладчика с очередной идиотской шуткой и т.п.) и плохого качества самой съемки, смотреть и слушать было крайне неприятно и затруднительно (удавил бы собственными руками ту барышню, которая начала что-то вещать прямо под видеокамерой, когда автор показывал и объяснял единственный слайд, посвященный обеспечению безопасности ).

Чувство глубокого недоумения вызвали в т.ч. следующие фразы:

...им (пользователям — прим. мое) нужен универсальный тонкий клиент...

им не нужен "универсальный тонкий клиент", они вообще не поймут о чем идет речь, если им выдать эту формулировку, т.к. мыслят иными категориями и понятиями

...пользователю, существующему в сетевом приложении нужен комфорт...

Газонокосильщик наносит ответный удар?

...практически идентична библиотеке QT и мы находим в этом дополнительное преимущество, потому что во-первых — это C++...

да, "потому что это С++" это конечно неоспоримое преимущество, не требующее каких-либо пояснений, я не спорю.

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

Теперь по делу. Ровным счетом ничего нового помимо того, что уже было озвучено ранее в дискуссиях КСВ я там не увидел Ну, кроме истории о загадочных но суровых госзаказчиках, грозящих отобрать его GPL-код со всеми потрохами, из-за которых он и находится сейчас в раздумьях — открывать его или нет. Детский сад, IMHO.

Полазил по блогу автора, в поисках инфы о решении вопросов безопасности в его продукте. Нашел только это. Ок, разберем подробнее:

Система должна быть защищена от возможных утечек данных и несанкционированного доступа.

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

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

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

Доступ к информационному ресурсу возможен только через специальный интерфейс.

security by obscurity? Или все же стоило уделить чуть больше внимания тому, что это за специальный интерфейс, и каким чудесным образом он закрывает ровно все риски связанные с нарушением конфиденциальности информации и приводит к:

Злоумышленное копирование информации невозможно.

"Не верю" (с) т.к. никаких предпосылок к этому выше озвучено не было

Носимые персональные компьютеры не становятся зоной риска утечки информации.

Как бы так помягче сказать... Носимые ПК составляют, ну, навскидку, около 3-5% от общей площади этой самой зоны, когда речь идет об информации, циркулирующей в сетевых приложениях

Удаленные малые офисы с недостаточно развитым режимом безопасности защищены от утечек и блокирования работы

Опять-таки каким образом, если все вышесказанное относится к 5% зоны риска нарушения конфидециальности информации (а это только одна информационная угроза из шести возможных)?

через информационное рейдерство

если бы автор знал определение выделенного термина, то постеснялся бы использовать его в этом контексте. Видимо он решил, что это какой-то баззворд из отрасли ИБ? Увы, он ошибся.

или иные жесткие меры воздействия.

Я прошу прощения, а от паяльника в ж%;е ведга случайно не спасает?

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

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

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, kochetkov.vladimir, вы писали:

k>> Так, попробуем зайти с другого конца. Ведга держит открытый сокет на каждого клиента?
S>Ведга вообще держит отдельный поток (или форк. Раньше были форки, но автор говорил что переводит нав потоки) на каждого клиента.

Что мне мешает с 10 рабочих станций инициировать 100 тысяч клиентских соединений на сервер ведги? Что произойдет в этом случае?

Здравствуйте, gandjustas, Вы писали:

G>>>Возьми 1С и добавь туда адресуемость.

H>>Ты невнимательно читал:
H>>

Если при разработке данное требование озвучено не вижу проблем для реализации

H>>Более того, учитывая программируемость 1С, у меня есть основания предполагать, что это таки возможно.

G>Ну так сделай. Или хотябы оцентку трудозатрат приведи.

Я не специалист по 1C. Никогда не писал под нее и надеюсь не придется. Но не думаю, что какой нибудь "касса\приход\3465" трудно распарсить и спозиционировать приложение.

G>Это только кажется что так просто все. Если изначально в архитектуру не заложена адресуемость, то прикрутить её проблематично.

В Янусе/Авалоне она тоже не заложена, однако реализовать ее там, я уверен, проще простого. Если до сих пор ее там нет значит нафиг не нужна.

G>Ждать что заказчик тебе скажет про адресуемость не стоит, зачастую это вопрос юзабилити, а не функциональных требований.

Вопросы юзабилити обсуждаются на этапе согласования интерфейса с заказчиком

Приветствую, Antikrot, вы писали:

A> а тогда какого чёрта мы в КСВ обсуждаем цитату автора о необходимости общения "традиционного" веб-приложения с прокси-сервером?

А у организаций не бывает мобильных работников, допофисов итд?

Здравствуйте, Sheridan, Вы писали:

g>> S>Напоминаю что в случае ведга-приложения контекст клиента сервер никогда не теряет.
g>> То есть держит открытое соединение, что очень плохо в плане расходования ресурсов.
S>Поподробнее.
Держать открытие сокеты — небесплатно. Кроме того при поддержке постянного соединения нет возможности балансировки нагрузки.

Кроме самого сокета удерживается еще все состояние интерфейса, которое и так присуствует на клиенте.

g>> S>Чем меньше выполняется на клиенте — тем меньше проблем.
g>> Напиши сразу что это для тебя очевидно, чтобы все сразу поняли что ты неправ и мне не пришлось бы это объяснять.
S>Нет уж, объясни. И не надо говорить за других.

В идеале сервер должен быть stateless для увеличения пиковой пропускной способности и повышения масштабируемости. При этом почти любой UI — statefull. Вот чтобы state не таскать на сервер лучше иметь возможность иметь некоторую логику на клиенте.

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, gandjustas, Вы писали:

G>>>>Возьми 1С и добавь туда адресуемость.

H>>>Ты невнимательно читал:
H>>>

Если при разработке данное требование озвучено не вижу проблем для реализации

H>>>Более того, учитывая программируемость 1С, у меня есть основания предполагать, что это таки возможно.

G>>Ну так сделай. Или хотябы оцентку трудозатрат приведи.

H>Я не специалист по 1C. Никогда не писал под нее и надеюсь не придется. Но не думаю, что какой нибудь "касса\приход\3465" трудно распарсить и спозиционировать приложение.

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

Можешь почитать как работает навигация в WPF, там множество тонких моментов возникает.

G>>Ждать что заказчик тебе скажет про адресуемость не стоит, зачастую это вопрос юзабилити, а не функциональных требований.
H>Вопросы юзабилити обсуждаются на этапе согласования интерфейса с заказчиком
Ну если нарисуете инерфейс с навигацией, то заказчик согласует такой. Без навигации — тоже согласует.

Здравствуйте, Sheridan, Вы писали:
S>Впрочем он критичен практически везде.
При работе через ремут-десктоп — нет. Разорвалось соединение — пофиг. Восстановил, залогинился, продолжил работать. С простым html — аналогично — все состояние — в куках, строке адреса, на сервере — обычно достаточно обновить страничку после восстановления коннекта. С ajax/flex/silverlight — момент коннекта к серверу явно прописан — ошибку коннекта можно обработать в коде.

S>...в этом направлении Олег тоже работал
S>Я знаю лишь что какието изменения были.
Вот-вот. Что-то делалось, а что — непонятно.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, Mr.Cat, вы писали:

MC>> А если клиент отсоединится? У меня вот, бывает, роутер заглючит, вайфай нечаянно выключу или еще чего — куда контекст денется?
S>Чудес не бывает, хотя в этом направлении Олег тоже работал. Я не знаю как сейчас, но когда я писал под ведгу — обрыв связи был критичен. Впрочем он критичен практически везде.

он некритичен в stateless системах. и это их преимущество — разумно используется сеть. да-да, у ведги есть такой недостаток, как у терминалок.

Приветствую, kochetkov.vladimir, вы писали:

k> S>Ведга вообще держит отдельный поток (или форк. Раньше были форки, но автор говорил что переводит нав потоки) на каждого клиента.

k> Что мне мешает с 10 рабочих станций инициировать 100 тысяч клиентских соединений на сервер ведги? Что произойдет в этом случае?
Гм. Будет подтормаживать скорее всего. Серебряной пули нет.
Вот вы интересные... А если я в серверной mail.ru тонну динамита взорву — mail.ru работать будет?

M>> S>Мамут. Твой софт — дерьмо. Я его правда не видет и ине трогал. Но он — дерьмо. Пока не докажешь обратное.
M>> S>Приятно?
M>> S>Вот приблизительно это ты и заявляешь со всей прямотой.

M>> Так и есть. Понимаешь, именно так и работает индустрия. И я к этому спокойно отношусь, в отличие от. Ценность и полезность каких-либо решений надо доказывать. Причем доказывать убедительно.

S>Мамут, мы нихера не конкуренты, так что меня можно и не обливать дерьмом.

А причем тут конкуренты-не конкуренты?

S>В двух словах: некий заказчик обещает забрать у него все, вместе с ведгой, лишив авторских и прочих прав итд.

Хм. Странная ситуация. Такое может быть только если сама ведга была написана по заказу этого заказчика Но такое тоже вполне может быть

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, kochetkov.vladimir, вы писали:

k>> S>Ведга вообще держит отдельный поток (или форк. Раньше были форки, но автор говорил что переводит нав потоки) на каждого клиента.

k>> Что мне мешает с 10 рабочих станций инициировать 100 тысяч клиентских соединений на сервер ведги? Что произойдет в этом случае?
S>Гм. Будет подтормаживать скорее всего. Серебряной пули нет.

Признайся честно — из какой вселенной вы пришли чтобы захавать нашу Землю? В каком измерении ОС, поддерживающая работу 100 тысяч одновременных потоков, активно работающих с сетью на каждый чих любой из 100 тысяч клиентских систем, будет "подтормаживать"?

S>Вот вы интересные... А если я в серверной mail.ru тонну динамита взорву — mail.ru работать будет?

Я не знаю, чем тебе не угодил mail.ru, но если ты это сделаешь у нас (в конторе, в датацентре МСК), то в столице пропадет наша сотовая связь примерно на 2-3 минуты, а регионах этого не ощутят вообще

g>>> S>Напоминаю что в случае ведга-приложения контекст клиента сервер никогда не теряет.
g>>> То есть держит открытое соединение, что очень плохо в плане расходования ресурсов.
S>>Поподробнее.
G>Держать открытие сокеты — небесплатно. Кроме того при поддержке постянного соединения нет возможности балансировки нагрузки.

G>Кроме самого сокета удерживается еще все состояние интерфейса, которое и так присуствует на клиенте.

Там еще дополнительно хуже. На каждого нового клиента к этому же приложению делается fork всего приложения.

Здравствуйте, gandjustas, Вы писали:

H>>Я не специалист по 1C. Никогда не писал под нее и надеюсь не придется. Но не думаю, что какой нибудь "касса\приход\3465" трудно распарсить и спозиционировать приложение.

G>Ну распарсить — полбеды. А вот что значит "спозиционировать приложение" ? А история навигации будет? Как она будет работать?
G>А что будет если я введу данные, а потом перейду по ссылке, не сохранив ничего и вернусь назад?

Как реализуешь так и будет. В чем тут вопрос? Другое дело, нужно ли это все, а вот на этот счет у меня есть большие сомнения.

G>Можешь почитать как работает навигация в WPF, там множество тонких моментов возникает.

Зачем мне навигая ради навигации

G>>>Ждать что заказчик тебе скажет про адресуемость не стоит, зачастую это вопрос юзабилити, а не функциональных требований.
H>>Вопросы юзабилити обсуждаются на этапе согласования интерфейса с заказчиком
G>Ну если нарисуете инерфейс с навигацией, то заказчик согласует такой. Без навигации — тоже согласует.

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

Здравствуйте, hattab, Вы писали:


G>>>>Ждать что заказчик тебе скажет про адресуемость не стоит, зачастую это вопрос юзабилити, а не функциональных требований.
H>>>Вопросы юзабилити обсуждаются на этапе согласования интерфейса с заказчиком
G>>Ну если нарисуете инерфейс с навигацией, то заказчик согласует такой. Без навигации — тоже согласует.

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

Приветствую, Mamut, вы писали:

M> S>В двух словах: некий заказчик обещает забрать у него все, вместе с ведгой, лишив авторских и прочих прав итд.
M> Хм. Странная ситуация. Такое может быть только если сама ведга была написана по заказу этого заказчика Но такое тоже вполне может быть
Нет, ведга разрабатывалась Олегом. Он ее задумал и начал писать еще во времена 3го кутэ.

Приветствую, kochetkov.vladimir, вы писали:

k> S>Гм. Будет подтормаживать скорее всего. Серебряной пули нет.

k> Признайся честно — из какой вселенной вы пришли чтобы захавать нашу Землю? В каком измерении ОС, поддерживающая работу 100 тысяч одновременных потоков, активно работающих с сетью на каждый чих любой из 100 тысяч клиентских систем, будет "подтормаживать"?
Ты просто не указал на каком серванте это дело поднято будет и какого типа приложение

Здравствуйте, gandjustas, Вы писали:

H>>Пардон, тут адресуемость называют чуть ли не обязательной фичей. При таком раскладе заказчик вряд ли забудет на это указать.
G>Еще раз. Навигация больше касается юзабилити. заказчики зачастую не могут все функциональные требования описать, не что нефункциональные (к которым юзабилити и относится).

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

M>> S>В двух словах: некий заказчик обещает забрать у него все, вместе с ведгой, лишив авторских и прочих прав итд.
M>> Хм. Странная ситуация. Такое может быть только если сама ведга была написана по заказу этого заказчика Но такое тоже вполне может быть
S>Нет, ведга разрабатывалась Олегом. Он ее задумал и начал писать еще во времена 3го кутэ.

Тогда не понимаю, кто и как может забрать все, вместе с ведгой и лишить авторских прав

Приветствую, Mamut, вы писали:

M> Тогда не понимаю, кто и как может забрать все, вместе с ведгой и лишить авторских прав

Это Россия, друг....
Посмотри наконец видео.

k>> S>Гм. Будет подтормаживать скорее всего. Серебряной пули нет.

k>> Признайся честно — из какой вселенной вы пришли чтобы захавать нашу Землю? В каком измерении ОС, поддерживающая работу 100 тысяч одновременных потоков, активно работающих с сетью на каждый чих любой из 100 тысяч клиентских систем, будет "подтормаживать"?
S>Ты просто не указал на каком серванте это дело поднято будет и какого типа приложение

100 тыс. клиентов. 20 байт на каждое телодвижение мышки.

100 000 * 20 = 2 000 000 байт = 16 000 000 bit = 15 Mbit. На каждое движение мышки в этих клиентах. И ведь load balancing нормально не сделаешь.

Приветствую, Mamut, вы писали:

M> k>> S>Гм. Будет подтормаживать скорее всего. Серебряной пули нет.

M> k>> Признайся честно — из какой вселенной вы пришли чтобы захавать нашу Землю? В каком измерении ОС, поддерживающая работу 100 тысяч одновременных потоков, активно работающих с сетью на каждый чих любой из 100 тысяч клиентских систем, будет "подтормаживать"?

M> S>Ты просто не указал на каком серванте это дело поднято будет и какого типа приложение

M> 100 тыс. клиентов. 20 байт на каждое телодвижение мышки.
Неверно. Впрочем можно конечно каждое телоджвижение мыша на сервер отправлять, но зачем?
По сети ходят только сигналы от контролов, интерфейс и данные. Тоесть движение мыша не отправляется. Отправляется к примеру клик по кнопке (десятки байт), да и то, если сигнал прописан.

M> 100 000 * 20 = 2 000 000 байт = 16 000 000 bit = 15 Mbit. На каждое движение мышки в этих клиентах. И ведь load balancing нормально не сделаешь.
Неверный вывод основанный на неверном предположении.

M>> 100 тыс. клиентов. 20 байт на каждое телодвижение мышки.
S>Неверно. Впрочем можно конечно каждое телоджвижение мыша на сервер отправлять, но зачем?
S>По сети ходят только сигналы от контролов, интерфейс и данные. Тоесть движение мыша не отправляется. Отправляется к примеру клик по кнопке (десятки байт), да и то, если сигнал прописан.

M>> 100 000 * 20 = 2 000 000 байт = 16 000 000 bit = 15 Mbit. На каждое движение мышки в этих клиентах. И ведь load balancing нормально не сделаешь.
S>Неверный вывод основанный на неверном предположении.

Одно (два?) слово: drag and drop

Здравствуйте, Mamut, Вы писали:

M> 100 тыс. клиентов.

Не получится на одном IP с постоянными соединениями.

Приветствую, Anton Batenev, вы писали:

AB> M> 100 тыс. клиентов.
AB> Не получится на одном IP с постоянными соединениями.
Ну у нас процессор в памяти

Автор: Sheridan
Дата: 27.11.09

, нам все можно.

Здравствуйте, Sheridan, Вы писали:

S> AB> M> 100 тыс. клиентов.
S> AB> Не получится на одном IP с постоянными соединениями.
S> Ну у нас процессор в памяти

Автор: Sheridan
Дата: 27.11.09

, нам все можно.

А это к процессору не имеет отношения

Здравствуйте, Mr.Cat, Вы писали:

S>>Впрочем он критичен практически везде.
MC>При работе через ремут-десктоп — нет. Разорвалось соединение — пофиг. Восстановил, залогинился, продолжил работать. С простым html — аналогично — все состояние — в куках, строке адреса, на сервере — обычно достаточно обновить страничку после восстановления коннекта.

Никогда не видел на форумах посты по три раза? Всего лишь обрыв связи. А казалось бы — hhtp к нему устойчив...

MC>С ajax/flex/silverlight — момент коннекта к серверу явно прописан — ошибку коннекта можно обработать в коде.

Вообще при некоторых моделях построения приложения эти вопросы может и библиотека порешать. Тупо спросить пользователя например — уже забъём или попробуем еще разок пересоединиться.

S>>...в этом направлении Олег тоже работал
S>>Я знаю лишь что какието изменения были.
MC>Вот-вот. Что-то делалось, а что — непонятно.

Да вообще в толстых клиентах проблема с дропаньем контекста пользователя на стороне сервера вроде как не особо сложно решается. Явно отсоединился — бросаем контекст сразу, отвалился с ошибкой/просто не дает о себе знать — ждем какое-то время (время можно выбирать адаптивно, в зависимости от нагрузки). И ничего принципиально лучшего по-моему и не придумаешь...

Приветствую, Mamut, вы писали:

M> M>> 100 тыс. клиентов. 20 байт на каждое телодвижение мышки.
M> S>Неверно. Впрочем можно конечно каждое телоджвижение мыша на сервер отправлять, но зачем?
M> S>По сети ходят только сигналы от контролов, интерфейс и данные. Тоесть движение мыша не отправляется. Отправляется к примеру клик по кнопке (десятки байт), да и то, если сигнал прописан.
M> S>Неверный вывод основанный на неверном предположении.

M> Одно (два?) слово: drag and drop
Драгидроп — это по твоему "каждое телодвижение мыша"? о0

Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>Никогда не видел на форумах посты по три раза? Всего лишь обрыв связи. А казалось бы — hhtp к нему устойчив...
Видел тут пару раз. Также видел, что на некоторых форумах проблема с этим решена.

MC>>С ajax/flex/silverlight — момент коннекта к серверу явно прописан — ошибку коннекта можно обработать в коде.
ТКС>Вообще при некоторых моделях построения приложения эти вопросы может и библиотека порешать. Тупо спросить пользователя например — уже забъём или попробуем еще разок пересоединиться.
Ну или так.

ТКС>Да вообще в толстых клиентах проблема с дропаньем контекста пользователя на стороне сервера вроде как не особо сложно решается. Явно отсоединился — бросаем контекст сразу, отвалился с ошибкой/просто не дает о себе знать — ждем какое-то время (время можно выбирать адаптивно, в зависимости от нагрузки). И ничего принципиально лучшего по-моему и не придумаешь...
Все эти рассуждения замечательны (кстати, везде прослеживается возможность программиста писать какую-то логику, связанную с ошибками коннекта).
Один вопрос остается — а в ведге/кальпе как сделано-то? Что делает система по дефолту при проблемах с коннектом? Как программист может влиять на поведение системы в этом случае?

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>>Никогда не видел на форумах посты по три раза? Всего лишь обрыв связи. А казалось бы — hhtp к нему устойчив...
MC>Видел тут пару раз. Также видел, что на некоторых форумах проблема с этим решена.

Ну просто в случае http об этом специально думать надо, а не оно само собой силами протокола делается.

MC>>>С ajax/flex/silverlight — момент коннекта к серверу явно прописан — ошибку коннекта можно обработать в коде.
ТКС>>Вообще при некоторых моделях построения приложения эти вопросы может и библиотека порешать. Тупо спросить пользователя например — уже забъём или попробуем еще разок пересоединиться.
MC>Ну или так.

ТКС>>Да вообще в толстых клиентах проблема с дропаньем контекста пользователя на стороне сервера вроде как не особо сложно решается. Явно отсоединился — бросаем контекст сразу, отвалился с ошибкой/просто не дает о себе знать — ждем какое-то время (время можно выбирать адаптивно, в зависимости от нагрузки). И ничего принципиально лучшего по-моему и не придумаешь...
MC>Все эти рассуждения замечательны (кстати, везде прослеживается возможность программиста писать какую-то логику, связанную с ошибками коннекта).

Вообще-то это можно целиком на библиотечный код переложить — rpd клиент же в конце-концов как-то с реконнектами сам справляется. Ведга, как понимаю, с точки зрения клиентской функциональности (ни строчки кода не пишется прикладным программистом, просто визуализируется передаваемое с сервера состояние) к нему ближе всего.

MC>Один вопрос остается — а в ведге/кальпе как сделано-то? Что делает система по дефолту при проблемах с коннектом? Как программист может влиять на поведение системы в этом случае?

Да без понятия. Главное, все это разработчик библиотеки может прикрутить в лююой момент, никого не напрягая. Хотя он может конечно и забить, и тогда как с DCOM получится...

M>> M>> 100 тыс. клиентов. 20 байт на каждое телодвижение мышки.
M>> S>Неверно. Впрочем можно конечно каждое телоджвижение мыша на сервер отправлять, но зачем?
M>> S>По сети ходят только сигналы от контролов, интерфейс и данные. Тоесть движение мыша не отправляется. Отправляется к примеру клик по кнопке (десятки байт), да и то, если сигнал прописан.
M>> S>Неверный вывод основанный на неверном предположении.

M>> Одно (два?) слово: drag and drop
S>Драгидроп — это по твоему "каждое телодвижение мыша"? о0

hover и rollover-эффекты, драгндроп — это все движение мыши. ты или "утяжеляешь" клиент, позвояля ему самостоятельно решать, что делать в таком случае (в частности, не бегать на сервер за изменением состояния) или постоянно шлешь на сервер никому ненужную информацию. как там было с тим в ведге когда-то, не помню.

Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>Ну просто в случае http об этом специально думать надо, а не оно само собой силами протокола делается.
Ну да. Где-то надо думать, где-то не надо.

ТКС>Вообще-то это можно целиком на библиотечный код переложить — rpd клиент же в конце-концов как-то с реконнектами сам справляется. Ведга, как понимаю, с точки зрения клиентской функциональности (ни строчки кода не пишется прикладным программистом, просто визуализируется передаваемое с сервера состояние) к нему ближе всего.
А вот мне наоборот показалось, что автор противопоставлял ведгу rdp и ведга нацелена скорее на RIA — просто с автоматической организацией взаимодействия клиента и сервера. Впрочем, если ведга и правда нацелена быть аналогом rdp — тогда согласен.

Здравствуйте, Mr.Cat, Вы писали:

ТКС>>Вообще-то это можно целиком на библиотечный код переложить — rpd клиент же в конце-концов как-то с реконнектами сам справляется. Ведга, как понимаю, с точки зрения клиентской функциональности (ни строчки кода не пишется прикладным программистом, просто визуализируется передаваемое с сервера состояние) к нему ближе всего.
MC>А вот мне наоборот показалось, что автор противопоставлял ведгу rdp и ведга нацелена скорее на RIA — просто с автоматической организацией взаимодействия клиента и сервера. Впрочем, если ведга и правда нацелена быть аналогом rdp — тогда согласен.

Ну я просто отличий от rdp конкретно в этом аспекте не вижу. А от RIA — отличия очевидны, у RIA без клиентского не-библиотечного кода не обходится. А что про это думает автор, и вовсе не важно. Он и ошибаться может, и врать у него мотивов больше чем у всех остальных.

Приветствую, Mr.Cat, вы писали:

MC>Впрочем, если ведга и правда нацелена быть аналогом rdp — тогда согласен.
Да совершенно не аналог. Рдп,внс,радмин — это передача графики, координат мыша и нажатых кнопок по сети. Ведга оперирует описанием интерфейса, сигналами и данными.