Пара гвоздей в гроб html browser-based приложений

[IA72]

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

.NET 2
http://msdn.microsoft.com/msdnmag/issue ... fault.aspx

Разумный блог
http://primates.ximian.com/~miguel/arch ... pr-24.html

[f_evgeny]

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

.NET 2
http://msdn.microsoft.com/msdnmag/issue ... fault.aspx

Разумный блог
http://primates.ximian.com/~miguel/arch ... pr-24.html

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

[Seryi]

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

Честно говоря я как программист давно жду чего-то подобного. Писать приложения не будучи связанным протоколом HTTP очень заманчиво.
Собственно идея не новая - если бы Sun довел Java до ума в 1998, то мы бы уже 6 лет как имели бы такие приложения. К сожалению реализация ГУИ в Java-машине оказалась настолько кривой, что идея Java-апплетов практически провалилась.
Единственное серъезное приложения что я знаю, выполненное как апплет - это ICQ2Go. И несмотря на все старания и огромную работу команды ICQ приложение получилось все равно до невозможности тормозным.
А вот в Микрософт я почему-то верю, думаю он смогут сделать то что не смог в свое время Sun.

[A. Fig Lee]

Речь надо понимать идет чисто о Виндовс?
Иначе я сомневаюсь в способности МС создать чтолибо толковое для УНИХ.
На Виндовс может и отомрет, там оно и так большой роли не играло.
А на УНИХ платформах - жило, живет и будет жить.
Очень удобно - легко, просто без дополнительных серверов/приложений можно контролировать практически что угодно ремоутли.
Затраты на написание такого приложения очень низки и море кода уже сущетвует написанного. И главное - платформонезависимое.

[Волчара]

Avalon means also that these new "Web" applications can visually integrate with your OS, that can use native dialogs can use the functionality in the OS (like the local contact picker).

And building fat-clients is arguably easier than building good looking, integrated, secure web applications (notice: applications, not static web pages).

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

[Dmitry67]

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

.NET 2
http://msdn.microsoft.com/msdnmag/issue ... fault.aspx

Разумный блог
http://primates.ximian.com/~miguel/arch ... pr-24.html

Ну наконец то
Как меня за... все эти ублюдочные viewstate и программирование на смеси .Net с FORTRAN (имеется ввиду глобальные перемнные Session)

[Seryi]

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

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

[A. Fig Lee]

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

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

а в чем там принципиальная разница с апплетами? вендор другой?

[Seryi]

а в чем там принципиальная разница с апплетами? вендор другой?

Принципиальной разницы я не вижу.
А в мелочах - не сомневаюсь что Микрософт сделает (я даже скажу, что уже сделал) ГУИ в .NET реально быстрым, симпатичным и привычным пользователям, а не таким убогим как джавовский ГУИ.
Как я говорил раньше - я считаю что идея Java-апплетов была великолепной и провалилась во многом из-за отвратной реализации ГУИ в Java-машине.

[IA72]

Ссылка из вышеупомянутого блога. Читать, много думать

http://groups.google.com/groups?as_umsg ... 3@meer.net

[f_evgeny]

а в чем там принципиальная разница с апплетами? вендор другой?

Принципиальной разницы я не вижу.
А в мелочах - не сомневаюсь что Микрософт сделает (я даже скажу, что уже сделал) ГУИ в .NET реально быстрым, симпатичным и привычным пользователям, а не таким убогим как джавовский ГУИ.
Как я говорил раньше - я считаю что идея Java-апплетов была великолепной и провалилась во многом из-за отвратной реализации ГУИ в Java-машине.

Ведь были и кроме явы реализации аплетов, например Tcl/Tk Web Browser Plug-in, и легче и рпботал на обоих браузерах. Но остались они невостребованными. Может не очень-то и нужны?
Ведь в веб-программировании какие плюсы? Я считаю, такие:
- Программирование целиком на стороне сервера.
- Клиент, универсальный, браузер, более-менее стандартный на всех платформах.
- Клиент уже установлен практически везде, не надо апгрейдов, ничего не надо.
- С безопасностью проблемы уже более-менее ясны.
- Все сети заточены под работу данного клиента.
Недостатки?
- немного неудобная обратная связь.
- слабый язык на стороне клиента.
Устранит ли новая технология проблемы и сохранит ли преимущества? Неизвестно. А вот вирусов новых все ждут уже сейчас.

[Волчара]

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

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

ну джава сидит в своей песочнице и не вылазит. Я еще не видел вируса от джава машины. А мелкософт давно доказал свою возможность по быстрому и удобному распростренению вирусов

[Seryi]

ну джава сидит в своей песочнице и не вылазит. Я еще не видел вируса от джава машины. А мелкософт давно доказал свою возможность по быстрому и удобному распростренению вирусов

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

Кстати про .NET вирусы я тоже не слышал, но не считаю что это невозможно. Если платформа станет популярной - то будут и вирусы.
На Java вирусов мало лишь по той причине что платформа не завоевала популярности. Кстати один Java вирус я таки припоминаю. Нацеливался на дырку в VM и распространялся через апплеты.

[f_evgeny]

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

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

Как обычно. За счет лучшей интеграции с ОС клиента.

[Seryi]

Ведь были и кроме явы реализации аплетов, например Tcl/Tk Web Browser Plug-in, и легче и рпботал на обоих браузерах. Но остались они невостребованными. Может не очень-то и нужны?
Ведь в веб-программировании какие плюсы? Я считаю, такие:
- Программирование целиком на стороне сервера.
- Клиент, универсальный, браузер, более-менее стандартный на всех платформах.
- Клиент уже установлен практически везде, не надо апгрейдов, ничего не надо.
- С безопасностью проблемы уже более-менее ясны.
- Все сети заточены под работу данного клиента.
Недостатки?
- немного неудобная обратная связь.
- слабый язык на стороне клиента.
Устранит ли новая технология проблемы и сохранит ли преимущества? Неизвестно. А вот вирусов новых все ждут уже сейчас.

Я считаю что такие технологии ОЧЕНЬ нужны. Но для того чтобы они были успешны необходима комбинация хорошего технического решения (по вашим словам таким был Tcl/Tk Web Browser Plug-in, у меня нет оснований полагать что .NET будет хуже. Про Java же я уже говорил) и большой распространенности решения (Java была распространенной, Tcl/Tk нет. В способностях МС широко распространить .NET я не сомневаюсь)

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

[lxf]

Речь надо понимать идет чисто о Виндовс?
Иначе я сомневаюсь в способности МС создать чтолибо толковое для УНИХ.

Точнее Windows Intranet. Первыми падут корпоративные веб-сайты в Windows конторах.

[f_evgeny]

Ведь были и кроме явы реализации аплетов, например Tcl/Tk Web Browser Plug-in, и легче и рпботал на обоих браузерах. Но остались они невостребованными. Может не очень-то и нужны?
Ведь в веб-программировании какие плюсы? Я считаю, такие:
- Программирование целиком на стороне сервера.
- Клиент, универсальный, браузер, более-менее стандартный на всех платформах.
- Клиент уже установлен практически везде, не надо апгрейдов, ничего не надо.
- С безопасностью проблемы уже более-менее ясны.
- Все сети заточены под работу данного клиента.
Недостатки?
- немного неудобная обратная связь.
- слабый язык на стороне клиента.
Устранит ли новая технология проблемы и сохранит ли преимущества? Неизвестно. А вот вирусов новых все ждут уже сейчас.

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

[Dmitry67]

evgeny, какие отдельные модули ? какие удобства многопользовательской работы ?
Это отдельные модули которые данные друг к другу тащат через сотни перемнных в Session. Полный аналог Common в Фортране
При работе с базой приходится использовать connection pool, что сразу отрезает много интересных аещей таких как @@SPID, sp_getapplock со scope = Session, ну и т д
Когда от WinForms я попал в Web программирование, у меня было чувство что я перенесся лет на пятнадцать назад

[Palych]

evgeny, какие отдельные модули ? какие удобства многопользовательской работы ?
Это отдельные модули которые данные друг к другу тащат через сотни перемнных в Session. Полный аналог Common в Фортране
При работе с базой приходится использовать connection pool, что сразу отрезает много интересных аещей таких как @@SPID, sp_getapplock со scope = Session, ну и т д
Когда от WinForms я попал в Web программирование, у меня было чувство что я перенесся лет на пятнадцать назад

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

[f_evgeny]

evgeny, какие отдельные модули ? какие удобства многопользовательской работы ?
Это отдельные модули которые данные друг к другу тащат через сотни перемнных в Session. Полный аналог Common в Фортране
При работе с базой приходится использовать connection pool, что сразу отрезает много интересных аещей таких как @@SPID, sp_getapplock со scope = Session, ну и т д
Когда от WinForms я попал в Web программирование, у меня было чувство что я перенесся лет на пятнадцать назад

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

[Palych]

Это отдельные модули которые данные друг к другу тащат через сотни перемнных в Session. Полный аналог Common в Фортране
При работе с базой приходится использовать connection pool, что сразу отрезает много интересных аещей таких как @@SPID, sp_getapplock со scope = Session, ну и т д
Когда от WinForms я попал в Web программирование, у меня было чувство что я перенесся лет на пятнадцать назад

Ето потому что Вы не вникли в суть Веб-приложений. Или применяли технологию там где она не нужна.
Никто не заставляет использовать Session attributes. И они слабо похожи на Common в Фортране.
То же самое про connection pools - можно открывать цоннецтион на каждый запрос, или на каждый Thread, просто pools и Request/Session/Application attributes позволяют более рационально распоряжаться ресурсами.

[Dmitry67]

2 palych
Да. Можно не пользоваться connection pool. Но во первых при этом скорость падает раз в пять, а во вторых @@spid и блокировками Вы все равно воспользоваться не сможете

По поводу того что же делать - так вот в статье и ответ

2 evgeny
Форум не тянет на Web приложение, слишком прост
Клик на странице и читаете минуту
Для WEB приложений характерно высокая степень интерактивности (обращение к серверу раз в две секунды, раз в секунду или чаще), очень сложная логика, и вследствие жтого отсутствие клавиш Вперед Назад, которые становятся бессмысленными

А что касается количества коннекций то неужели 6000 threads не потянуть ?

Теперь о корне этого зла
Первоначально http был рассчитан на stateless работы, да и понятия сессии в древние времена не было
Потом все стало усложняться, ввели сессии

WEB приложения очень сложны и совершенно не stateless. Корень зла в том, что реализовывать аюсолютно не-stateless вещь stateless средствами жто мука

[Seryi]

Я вижу преимущество новых технологий как та о которой топик не в отказе от Веб вообще. Я просто думаю что

а) HTML был придуман как средство передачи информации и очень плохо предназначен для построения пользовательских интерфейсов. Программировать на клиентском javascript - это то еще удовольствие.
b) stateless идея HTTP протокола очень неудобна для построения интерактивных приложений.

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

[f_evgeny]

2 evgeny
Форум не тянет на Web приложение, слишком прост
Клик на странице и читаете минуту
Для WEB приложений характерно высокая степень интерактивности (обращение к серверу раз в две секунды, раз в секунду или чаще), очень сложная логика, и вследствие жтого отсутствие клавиш Вперед Назад, которые становятся бессмысленными

Не понял, это один клиент обращается к серверу раз в секунду? Он что в тетрис играет? Или новое поколение суперлюдей?
Или это автомат? С автоматическим обменом с сервером?
Ну я делаю такие автоматические штуки, на базе Apache/php/http/xml. Можно сделать и без него, на сокетах, и С. Но только боюсь это займет в 10-20-100 раз больше времени, а работать будет хуже.
И как Вы обойдетесь без сессий?
Ну, я знаю некоторые варианты, например, работа в терминальном режиме, но боюсь, Вам они тоже не понравятся.

[Dmitry67]

Согласен с Seryi

2 f_evgeny
Мы делаем... грубо говоря жто очень специализированный редактор докукментов сложной структуры
Каждая маленткое поле имеет историю изменений, список подписей итд
А интерактивность работы с редактором сами понимаете какая