https://slinkov.ru/openforum/vsluhforumID3/40385.html "Тонкий сервер (http://abava.blogspot.com/2008/02/blog-post_27.html)" - архитектура "тонкий сервер", когда логика обработки данных переносится на плечи клиента.<br><br>URL: http://abava.blogspot.com/2008/02/blog-post_27.html<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=14444<br> https://slinkov.ru/openforum/vsluhforumID3/40385.html#17 Fri, 29 Feb 2008 00:58:19 GMT &gt;А что, связка "тонкий" клиент и "тонкий" сервер может работать? <br><br>напиши статейко и проанализируй это.<br><br>Какие-то глупости пошли уже не по существу<br> https://slinkov.ru/openforum/vsluhforumID3/40385.html#16 Thu, 28 Feb 2008 21:31:02 GMT &gt;Ну, сам придумал что тема о "толстом" клиенте - и понесло... <br>&gt;<br>&gt;Не было об этом разговора. <br><br>А что, связка "тонкий" клиент и "тонкий" сервер может работать?<br><br> https://slinkov.ru/openforum/vsluhforumID3/40385.html#15 Thu, 28 Feb 2008 21:21:44 GMT так бреттодо или бреддото?<br> https://slinkov.ru/openforum/vsluhforumID3/40385.html#14 Thu, 28 Feb 2008 19:04:46 GMT &gt;Каша какая-то. Покажите мне "тонкий" клиент на хтмл но без java/javascript? А <br>&gt;те что со скриптами автоматом к "толстым" приравниваются? <br><br>читай сабж.<br>Речь о "тонком" сервере, а не о "толстом" клиенте.<br>Не нужно тут в поломанный телефон играть...<br><br><br>&gt;Вот для меня "толстый" клиент, это например продукт ЕМЕ, может кто слышал <br>&gt;о таком (компания Нестле такой точно юзала). Там есть сервер, но <br>&gt;рулит не многим, транзакции, синхронизация, свой движок для бд, а копия <br>&gt;данных все равно на стороне клиента есть(нужных ему и не нужных), <br>&gt;которые он повредить может. А когда данные на стороне сервера, сервер <br>&gt;ими распоряжается, а на стороне клиента только рендереинг и простейшие скрипты, <br>&gt;то какой же он "толстый".<br><br>Ну, сам придумал что тема о "толстом" клиенте - и понесло...<br><br>Не было об этом разговора.<br> https://slinkov.ru/openforum/vsluhforumID3/40385.html#13 Thu, 28 Feb 2008 18:36:02 GMT Каша какая-то. Покажите мне "тонкий" клиент на хтмл но без java/javascript? А те что со скриптами автоматом к "толстым" приравниваются?<br><br>Вот для меня "толстый" клиент, это например продукт ЕМЕ, может кто слышал о таком (компания Нестле такой точно юзала). Там есть сервер, но рулит не многим, транзакции, синхронизация, свой движок для бд, а копия данных все равно на стороне клиента есть(нужных ему и не нужных), которые он повредить может. А когда данные на стороне сервера, сервер ими распоряжается, а на стороне клиента только рендереинг и простейшие скрипты, то какой же он "толстый".<br> https://slinkov.ru/openforum/vsluhforumID3/40385.html#12 Thu, 28 Feb 2008 18:20:12 GMT А я вот увидел рациональное зерно в статейке (кроме кеширования запросов к другим серваисам %)<br><br><br>&gt;Сдается мне, получим проблемы децентрализации, от которых старались уйти долгие годы: <br>&gt;1. неоднозначность выполнения скрипта на клиенте, <br><br>если уж на то пошло - то даже в HTML'е нет полной однозначности среди отображения<br>во всех браузерах. Так чем же JavaScript принципиально хуже? Хоть так хоть так пришлось бы<br>затачивать клиент-код под определенный браузер.<br><br><br>&gt;2. возможность правки кода на клиенте: клиентская часть решает, какие пункты меню <br>&gt;будут доступны? Это безопасность?<br><br>ессьно, клиент пусть решает что ему взбредет. Но правомерность его запросов будет определятся на сервере. Это - безопасность.<br><br><br>&gt;4. Кто в этом случае хранит обрабатываемые данные? Клиент? Очень защищенное от <br>&gt;сбоев решение...<br><br>Данные путем запросов отправляюццо на сервер, а там уже - как тебе нравится.<br>Так что да, защита от сбоев лишь в руках админа.<br><br><br>&gt;5. &gt;&gt;вы оcновное в этом подходе не поняли - код не загружается от https://slinkov.ru/openforum/vsluhforumID3/40385.html#11 Thu, 28 Feb 2008 14:11:29 GMT Сдается мне, получим проблемы децентрализации, от которых старались уйти долгие годы:<br>1. неоднозначность выполнения скрипта на клиенте, <br>2. возможность правки кода на клиенте: клиентская часть решает, какие пункты меню будут доступны? Это безопасность?<br>3. "не в базу напрямую" - это круто, Jumla тоже не напрямую в базу дает лезть, а всего лишь через параметры, можно отправить лекторов к milw0rm.<br>4. Кто в этом случае хранит обрабатываемые данные? Клиент? Очень защищенное от сбоев решение...<br>5. &gt;&gt;вы оcновное в этом подходе не поняли - код не загружается отдельно клиентом. Он получает его с веб-страницы.<br>Нет слов. А веб страница где? не на клиенте? Я почему-то думал, что страница живет в клиентском браузере, который может интерпретировать этот код, как ему заблагорассудится.<br>6. На кой черт проксировать запросы к другим ресурсам? Если ресурс мертв, данные проксика не валидны, если жив - их чудное приложение на клиенте может и само обрабатывать список зеркал, например.<br>7. Какая бизнес-логика? Кто решает, чт https://slinkov.ru/openforum/vsluhforumID3/40385.html#10 Thu, 28 Feb 2008 11:51:22 GMT &gt;А что помешает клиенту сфабриковать подложный запрос (например, при помощи исправления полученных <br>&gt;Java-скриптов) и отправить его на сервер? <br><br>Вы же не в базу напрямую лезете, а говорите "хочу новости" и вам отдают блок новостей, тольно не в HTML, а в JSON, то что не положено вам не отдадут, точно также как если бы логика была целиком на сервере.<br> https://slinkov.ru/openforum/vsluhforumID3/40385.html#9 Thu, 28 Feb 2008 11:36:49 GMT А что помешает клиенту сфабриковать подложный запрос (например, при помощи исправления полученных Java-скриптов) и отправить его на сервер?<br>