| 1.1, leonid.ko (?), 21:30, 27/02/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>- за сервером остается только следующий функционал:
>a) безопасность
>б) бизнес-логика
>в) проксирование запросов к другим ресурсам
что то терзают смутные сомнения меня по поводу пункта а)
| | |
| 1.2, andruffka (ok), 22:12, 27/02/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Статья эта должна заканчиваться советом по возможности не использовать эту технологию.
Т.к. функции безопасности в этом случае - фикция, в связи с чем бизнес-логику можно нарушить, лишний трафик между сервером и клиентом, более мощные и следовательно более дорогие машины для клиентов. Чем больше кода на стороне клиента и чем разношерстнее эти клиенты, тем больше багов и сложнее их устранение, и т.д. и т.п.
| | |
| |
| 2.5, Денис (??), 10:00, 28/02/2008 [^] [^^] [^^^] [ответить]
| +/– |
 >Чем больше кода на стороне клиента и чем разношерстнее эти клиенты,
вы оcновное в этом подходе не поняли - код не загружается отдельно клиентом. Он получает его с веб-страницы. Как он может быть разношерстным? И правится (в случае необходимости) он опять таки в одном месте - на сервере
| | |
|
| 1.3, Jet (??), 22:29, 27/02/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Соответственно, одна из основных проблем в разработке "толстых" клиентов - как >заставить пользователя загрузить и обновить приложение, когда что-то в логике >поменялось, здесь не существует. Обработчик автоматически загружается в браузер >клиента, когда он заходит на веб-страницу. Цель вполне очевидна - разгрузить >сервер, сделать приложение более масштабируемым.
Боже, какой бред.....
| | |
| 1.4, Алекс (??), 06:21, 28/02/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Опус в стиле "пшик" в сторону распределённых вычислений. Почесать затылок и сказать себе честно - мы нихрена не понимаем в распределённых вычислениях или понимаем но нихрена никому не раскажем.
| | |
| |
| 2.6, Денис (??), 10:05, 28/02/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Опус в стиле "пшик" в сторону распределённых вычислений. Почесать затылок и сказать
>себе честно - мы нихрена не понимаем в распределённых вычислениях или
>понимаем но нихрена никому не раскажем.
нет, к распределенным вычислениям это отношения не имеет. Все централизованно, клиенты взаимодействуют только сервером etc. По факту для веб-приложений - это просто систематизация шаблонов проектирования, привязанных к слову JSON. Это там правильно написано - ноги отсюда растут
| | |
|
| |
| 2.8, uldus (ok), 12:59, 28/02/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>Интересно, каким образом можно к ЭТОМУ прикрутить безопасность?
Подразумевается, что сервер отдает только данные в JSON, а JavaScript клиента стоит страницу. Безопасность получается даже выше, за счет выноса логики построения интерфейса с сервера. В обычных условиях сервер вернул те же данные по томуже запросу, но в красивой обертке.
| | |
| |
| 3.9, Keeper (??), 14:36, 28/02/2008 [^] [^^] [^^^] [ответить]
| +/– |
 А что помешает клиенту сфабриковать подложный запрос (например, при помощи исправления полученных Java-скриптов) и отправить его на сервер?
| | |
| |
| 4.10, uldus (ok), 14:51, 28/02/2008 [^] [^^] [^^^] [ответить]
| +/– |
>А что помешает клиенту сфабриковать подложный запрос (например, при помощи исправления полученных
>Java-скриптов) и отправить его на сервер?
Вы же не в базу напрямую лезете, а говорите "хочу новости" и вам отдают блок новостей, тольно не в HTML, а в JSON, то что не положено вам не отдадут, точно также как если бы логика была целиком на сервере.
| | |
|
|
|
| 1.11, Serg (??), 17:11, 28/02/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Сдается мне, получим проблемы децентрализации, от которых старались уйти долгие годы:
1. неоднозначность выполнения скрипта на клиенте,
2. возможность правки кода на клиенте: клиентская часть решает, какие пункты меню будут доступны? Это безопасность?
3. "не в базу напрямую" - это круто, Jumla тоже не напрямую в базу дает лезть, а всего лишь через параметры, можно отправить лекторов к milw0rm.
4. Кто в этом случае хранит обрабатываемые данные? Клиент? Очень защищенное от сбоев решение...
5. >>вы оcновное в этом подходе не поняли - код не загружается отдельно клиентом. Он получает его с веб-страницы.
Нет слов. А веб страница где? не на клиенте? Я почему-то думал, что страница живет в клиентском браузере, который может интерпретировать этот код, как ему заблагорассудится.
6. На кой черт проксировать запросы к другим ресурсам? Если ресурс мертв, данные проксика не валидны, если жив - их чудное приложение на клиенте может и само обрабатывать список зеркал, например.
7. Какая бизнес-логика? Кто решает, что будет видеть клиент? сервер? На основе тех данных и параметров, которые я могу задать в отладчике жабаскрипта?
А давайте вернемся к отоплению жилья углем - от него дым прикольный... :)
| | |
| |
| 2.12, Nick (??), 21:20, 28/02/2008 [^] [^^] [^^^] [ответить] | +/– |  А я вот увидел рациональное зерно в статейке кроме кеширования запросов к други... большой текст свёрнут, показать | | |
| |
| 3.13, andruffka (ok), 21:36, 28/02/2008 [^] [^^] [^^^] [ответить]
| +/– | |
Каша какая-то. Покажите мне "тонкий" клиент на хтмл но без java/javascript? А те что со скриптами автоматом к "толстым" приравниваются?
Вот для меня "толстый" клиент, это например продукт ЕМЕ, может кто слышал о таком (компания Нестле такой точно юзала). Там есть сервер, но рулит не многим, транзакции, синхронизация, свой движок для бд, а копия данных все равно на стороне клиента есть(нужных ему и не нужных), которые он повредить может. А когда данные на стороне сервера, сервер ими распоряжается, а на стороне клиента только рендереинг и простейшие скрипты, то какой же он "толстый".
| | |
| |
| 4.14, Nick (??), 22:04, 28/02/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Каша какая-то. Покажите мне "тонкий" клиент на хтмл но без java/javascript? А
>те что со скриптами автоматом к "толстым" приравниваются?
читай сабж.
Речь о "тонком" сервере, а не о "толстом" клиенте.
Не нужно тут в поломанный телефон играть...
>Вот для меня "толстый" клиент, это например продукт ЕМЕ, может кто слышал
>о таком (компания Нестле такой точно юзала). Там есть сервер, но
>рулит не многим, транзакции, синхронизация, свой движок для бд, а копия
>данных все равно на стороне клиента есть(нужных ему и не нужных),
>которые он повредить может. А когда данные на стороне сервера, сервер
>ими распоряжается, а на стороне клиента только рендереинг и простейшие скрипты,
>то какой же он "толстый".
Ну, сам придумал что тема о "толстом" клиенте - и понесло...
Не было об этом разговора.
| | |
| |
| 5.16, andruffka (ok), 00:31, 29/02/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Ну, сам придумал что тема о "толстом" клиенте - и понесло...
>
>Не было об этом разговора.
А что, связка "тонкий" клиент и "тонкий" сервер может работать?
| | |
| |
| 6.17, Nick (??), 03:58, 29/02/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>А что, связка "тонкий" клиент и "тонкий" сервер может работать?
напиши статейко и проанализируй это.
Какие-то глупости пошли уже не по существу
| | |
|
|
|
|
|
|
