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

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

Недостаёт нам понятия локального сервера, взаимодействующего с клиентом и наделённого некоторыми полномочиями по автоматическому запуску задач клиента на локальном компьютере - запись файлов, исполнение программ. Сейчас в клиентском языке этих функций не хватает, и появляется FileSystemObject, который берёт на себя часть функций, но не очень чёток в выборе полномочий. В интранете он работает, в интернете - проблемы. Следовательно, браузеру со скриптами надо отдать функции клиента в виртуальной машине, но ещё чётко обговорить 3-ю виртуальную машину в этой цепочке - локальный сервер. Её, как и удалённого сервера, надо снабдить пространством, ресурсами времени, планировщиком, и тогда клиенты вздохнут спокойно - на их машинах без внедрения сторонних технологий (машиннозависимые приложения) можно будет организовывать личные серверы, ведающие кешированием, отбром, сохранением важной информации. Клиент-браузер для них - посредник для общения с другими серверами и пользователем.

Могут возразить: есть же сервер-серверное сокетное взаимодействие, зачем это делать через клиента? Главная роль локального сервера - работать под контролем пользователя, чтобы он через браузер разрешил автоматизировать использование ресурсов своего компьютера в несколько большей мере, чем это делает браузер (без FSO и ActiveX). В частоности, лок.сервер может дать знать удалённому, что некоторые программы и данные он уже имеет, передавать их не надо.

Что вы думаете по этому поводу? Пойдёт ли лозунг "Даёшь сервер в каждый комп!" на ура? С тем, чтобы он подменил сателлитные браузерные технологии собой, участвовал в работе сети компьютеров на правах сервера. Да мало ли в какие новые пределы можно залить эту идею, главное, чтобы она осталась на своём месте - компьютере пользователя.

Собственно, как мне кажется, в случае Java-апплетов исполняющая среда (JRE) как раз и реализует эту самую модель "локального сервера".

Не вникнул в идею...

Если рассмотрим не модель "клиент-сервер" в целом, а вебсервер-веббраузер, то какова суть локального сервера? В возможности удалённому прогрммисту "как в песочнице" выполнять что нибудь у меня? Зачем, это будет жрать ресурсы, в 90% случаев не нужно и опасно, т.к. песочница это софт, а в софте всегда есть дыры.
(и только супер программа имеет супербаги, остаьлной софт содержит ошибки по определению  )

Приведи пример где это может применяться? Если мне нужно что бы в сети компы могли контролируемо работать друг с другом (вплоть до использования вычислительных ресурсов "соседа"), то лучше собрать P2P сеть, где большой акцент пойдёт на разграничение прав. А вообще кончай мыслить стереотипами/моделями, если нужно что бы сервер мог что нибудь делать на клиенте (положить куки, запросить список файлов в песочнице и т.д.), то просто расширь для этого протокол.

Не знаю, JRE обеспечивает доступ к ресурсам комп-а (файлы, порты, принтеры, запуск программ) при работе с апплетом?

Sardar, FSO и прочие объекты, работающие с ресурсами компьютера в JS. Я про то говорю - рутинное разделение прав, которое надо выделить в отдельную оболчку, а не смешивать её функции с языком браузера - апплетом или скриптом. Из мухи слона всегда можно сделать, но лучше мыслить моделями. 

Физически да, но потребуеться настроить (выдать) права на это.

Добавлено @ 19:33 

Неужели ты отдашь откроешь всему миру свой комп, вот вам песочница в 2ГБ, делайте что хотите? Начнёт мусор и вири у юзеров ютиться, хороший способ себя сохранить. Если дашь сеть, то будет спам рассылаться. Если дашь настройки (прокси и т.п.), то будут автоматом целые сети анонимайзеров строиться. Если дашь возможность запускать проги (в принципе это главное, покрывает всё упомянутое ранее), то можно всё... как только найдёться дыра 

На встречу: почему возникла такая мысль? Где конкретно может потребоваться такая функциональность? Почему ты уверен что это безопасно и необходимо для пользователя? 

12345c, правильно ли я тебя понял? ты имеешь в виду создание у пользователя виртуальной машины  со своей виртуальной файловой системой, памятью и т.д. ?

Если так, то мне такая идея нравиться. Локальный сервер эмулирует виртуальный компьютер. И загружаемое приложение может делать всё что угодно, но не выходя за рамки этого виртуального компьютера. С безопасностью лады, а дополнительная функциональность значительна. Таким образом, например, таким образом можно да хоть с БД на стороне клиента работать. Например, пользователь на сайте что-то делает и это надо сохранить. Сохранять на сервере - можно..., но если объемы большие, или требуется произвести длительные вычисления, или пользователю нужно из этого какой-то набор файлов получить и т.д. тогда лучше всё это делать у клиента в его выделенной для этих целей памяти, виртуальной файловой системе.

DemoCode, почему у пользователя? Я работаю с 4 компов: 2 на работе, ноут и домашний ком, тут даже идея плагин для мозиллы поставить, что бы настройки в вебе хранить, не то что файлы у себя 

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

Настройки, сессию, всю инфу можно и нужно хранить на сервере.

Есть такой, только в пятницу видел.

Это сообщение отредактировал(а) Lamer George - 5.8.2006, 11:29

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

С виртуальными машинами тут 2 момента: одна уже есть - при браузере, но с не очень гибкой моделью. Я предлагаю её в том же духе развивать, в каком она сейчас обрисовалась: скриптовой язык, куки, кеш, документ, окна. В локальном сервере нужна более действенная, и многие функции новых плагинов просятся туда, а не в архитектуру браузера. Плагины, виджеты, приложения - то, что не должно нагружать браузер, но должно с ним взаимодействовать.

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

Что может понадобиться юзеру в отношении веба?

• Более организованно управлять кешем. Значит, все программы, помогающие хранить в кеше (и куках) то, что нужно и побыстрее удалять ненужное, относятся к уровню лок.сервера.
• Переносить страницы и файлы из кеша в раздел постоянных хранимых данных. Если страница нужна, то процедура синхронизации позволяет видеть её из оффлайна. Но если страница обновилась, браузер норовит обновить запомненную страницу. Регулировать процесс обновления версий - задача лок.сервера. Я вижу эту функцию самой важной - умение работать с данными и при необходимости выдвавать сохранённую копию в веб (себе, не обязательно всем).
• захотелось нам достать данные из веба из домашнего компьютера. Если лок.сервер сможет работать как просто сервер, у нас нет необходимости пользоваться услугами других серверов.
• Пользоваться внешним сервером как синхронизатором данных и настроек - вот именно, для этого нужны программы, изобретают плагины. Вместо того, чтобы рассматривать как внешний сервер и группу своих компьютеров как сеть серверов и синхронизировать данные в них едиными методами.
•  При всём этом у лок. сервера ограниченные права, как у скриптов на обычном сервере. Шансы быть взломанными есть, как у всех серверов. Не хотите быть взломанными - не пользуйтесь интернетом или соответствующими системами.

Обоснуй, за пример возьми Mozilla/FireFox или любой другой Gecko браузер.


А разве это сейчас не так в ранее упомянутой лисе? Есть chrome, песочница для расширений браузера. Есть браузер, сам собранный на XUL/Х* как и его расширения.
Опиши с одним конкретным примером что есть взаимодействовать для тобой упомянутых приложения и браузера. Нарисуй словами любую софтину 


Вообще по теории кешей идеальный кешь не видим для того кто его использует 
На практике, как для процессора в твоём компе, так и для юзера с браузером полезно форсировать очищение кеша + требовать разного рода ограничений на кешь. Юзеры! поднимите руки те, кто лез в кешь не затем что бы его очистить, или в редких случаях достать картинку, что на сервере уже не доступна 
Уверен что большинству юзеров возможность как то разграничить кешь для разных прог совсем не нужна, вернее не будет использоваться. Но можно реализовать. Почему ты считаешь что кеш браузера (смотрим лису опять же) должен контролироваться отдельным локальным сервером? Всё что ты перечслил, может(должен) делать и сам браузер.


Ничего кроме как запретить доступ всем плагинам/прогам и показать юзеру эту страницу как есть, ты не можешь сделать. Есть секретные страницы, например страница моего банка где я получаю временный ключь на оплату счёта по инету. Разграничить доступ по сайтам? А по каким сайтам, все упомянуть? На второй день после релиза фича будет названа дырой в безопасности 


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


А если все компы выключены? У меня нет привычки оставлять домашний комп включёным. На работе компы всегда включены, но все входящие коннекты заблокированы (на моём домашнем кстати тоже). Вот она самая большая проблема: как обходить существующее сейчас секьюрити, писанное чуть ли не кровью, имея аргумент "мы тут сервер задумали, он не только входящие коннекты требует, но проги удалённо кому угодно позволит запускать" 
Резюмирую: как решить проблему с входящими конектами, глянь на спецификацию FTP протокола, из-за этой проблемы создан новый PASV режим (дата-канал открывает тоже клиент, в этом режиме все и работают, оригинальный канул в лету).


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

• множество компонент выполняющих точно свою работу, взлом компоненты не влияет на другую компоненту. За компоненты считай сервисы, сервера и т.д
• взломанная компонента предоставляет хакеру все возможные права и действия (позволяет запустить произвольный код), которые компонента может сделать. Права и возможности компоненты ограничиваються извне, так что взлом её не затрагивает ресурсов до которых у компоненты доступа не было (почтовый сервер имеет доступ только в /var/mail, открывать коннекты только по указанным портам или даже адресам, и т.д.).

Современные безопасные серверные оси строяться не на ресурсах доступных проге (ACL), а на действиях которые она может совершить. Действия выполняються либами, которые на самом деле делают запросы к другим прогам (сервисы обслуживающий TCP/IP, файловым системам, экрану и т.д.). Дргуими словами компонента работает в песочнице, саму песочницу сломать можно найдя баг (что почти не реально в виду простого API), только компонента являеться выходов "в мир" и потому с ней работают в перчатках 

Всё выше перечисленное редко встречаеться на пользовательских осях типа WinXP Home, открываеться ещё одна не нужная дырка, статьи в инете пишут о том как не безопасно ставить твою софтину, мелкософт выпускает патч для удаления твоей проги как трояна 

Негибкость модели виртуальной машины я подразумеваю в том, что признанные кроссбраузерные возможности её ограничены, а расширения привязаны к браузеру. Что бы нового инициативного не наворотили в браузере разработчики, это не признаётся другими (на каждый attachEvent найдётся свой addEventListener). Нет выхода в клиенте на естественную среду, в которой другие разработчики уже привыкли строить свои модели (среду лок.сервера). Если бы браузер описывал чёткое взаимодействие с удалённым сервером с одной стороны и локальным с другой, не было бы ни основы для развития плагинов - развивались бы программы. Браузеры не обрастали несвойственной им сложностью смежных приложений.

А если в датацентр попадёт бомба, а дискету пожуёт собака? 

Я выше примерно описывал - "умение работать с данными и при необходимости выдвавать сохранённую копию в веб". Например, программа-помощник юзера, показывающая его реальный каталог, который есть рабочее пространство виртуальной машины лок.сервера. В него юзер может сохранять файлы, из него обмениваться данными или давать доступ себе с другого комп-а или другим, рабочей группе. Главная идея в том, чтобы она работала как сервер и её создание ничем не отличалось для разных браузеров. И, естественно, она без браузера тоже может работать. Как и с браузером без веба, при оффлайне.

А к чему полемика про "Юзеры, поднимите руки,..."? Разве это не полезная функция, если бы она была рабочей - доставание из кеша? К примеру, мне при плохой связи прекрасно помогал прокси-сервер, показывающий страницы при незавершённой их загрузке (при разрыве связи). Он эмулировал улучшенную работу кеша по сравнению со стандартной.

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

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

Так, вырисовываетсья:

• есть некий сервер приложений, позволяющий безопасно хоть виря запустить, доступ строго ограничен на нужды веба. О проблемах я говорил раньше, та же возможность создавать исходящие коннекты (опрашивать погоду, курс валюты и т.д.) таким апплетами позволит апплету рассылать спам с компа пользователя. А если такая прога может быть установлена любым сервером без спроса пользователя (на нужды сайта), то вообще труба...  
• посредством сервера хотим создать некую стандартную среду. НО! внутреняя организация браузера не измениться, ибо его скриптовое API должно исполняться самим браузером, а не софтом третьих лиц. Представь ты пишешь браузер, хочешь принимать события мыши, но для этого ты должен отправить запрос локальному серверу выполнить эту работу за тебя. Тот вообще офигевший от такого будет отвечать "да" на всё, ибо события, рендеринг и прочее это браузеро зависимо и следовательно не в его компетенции. Новый стандарт? Засмеют же, и так W3C с трудом пробилась...
• серер может работать автономно, превращаясь некое подобие софта для удалённого администрирования, но ограниченное песочницой. Все браузеры должны поддерживать API сервера...  а зачем тут вообще бразуер? 
• не известно пока что конкретно будет делать браузер, а что сервер. Будет ли сервер просто спецификацией и реализовываться браузером или это отдельный софт. Не названы ни одной конкретной задачи где такой подход решил бы проблему.
• по не понятным причинам отторгаетсья "песочница" браузера, даже ИЕ с версии 7 такой обзавёлся для своих ActiveX, наконец их запускать можно будет.
• единственный плюс который я вижу это возможность писать апплеты, даже если браузер их не поддерживает, т.е. для браузера вставить API будет проще чем реализовать XPCOM как в мозилле. А как же с переносимостью? Или снова открываем Java? Да и вообще расширения браузера и "просто апплеты" это две разные материи...

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


А если серьёзно? У меня компы действительно выключены, да и никогда нет необходимости что то из домашнего компа достать. Иначе по закриптованному шеллу достану что мне нужно, а для большинства пользователей Radmin и просто домашние вебсерверы хорошее решение (естественно это открывает потенциальные уязвимости).


Зачем снабжать одну софтину кучей возможностей на все случаи жизни? Это как армейский нож, потом запаришся поддерживать и обновлять систему. Прокси сервер сейчас работает идеально, занимаеться кешированием и не просит поддержку апплетов. Зачем твой новый сервер в этой области?


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

конкретный вопрос: зачем мне в прокси сервере нужна способость работать с локальными ресурсами (с принтером например)? Ну стоят у меня несколько софтин отдельно: firewall, прокси, анализатор трафа(статистика), SSH сервер (доступ к системе) и многое другое, позволяющее контролируемо выдать доступ к ресурсам компа "в сеть". Если захочу, то могут поставит/настроить софт на что угодно, позволяющее это "что-угодно" делать удалённо, хоть печатать, хоть работать с файлами. Повторюсь, есть Radmin для виндовых юзеров если что.

Конкретный вопрос: зачем собирать функциональность разного софта в единый, да ешё соединять это с браузером? Функциональность ограничиваеться, переносимость убиваеться на корню (собственная VM?), обслуживать такой софт будет не реально (малые проекты развиваються быстро, а такой большой будет копить баги) и главное: кто возьмёт стандартизацию? В современном мире достаточно решений для всего что ты предложил в этом топе, вряд ли кто захочет поддерживать винегрет из всего этого.

Название топу можно было бы поменять на "Локальный сервер приложений и браузеры, размышления на тему перспективности проекта", ибо "модель клиент-сервер" тут никаким боком.

Совершенно верно.


Чтобы они собирали достоверную информацию. Хотя это удобная функция.


А если начнется война и не будет электричества. То... Что-то мне от этой мысли дурно становится.   

помоему бритва Оккама самый необходимый инструмент в разработке всех теоретический моделей.....

Тьма, правильно!!! Поэтому не надо браузеру придавать функции локального сервера .
Sardar, ой, опять длинно. 
я серьёзно - кому надо буднет, у того компы будут включены. (Странно, почему не делают устройств для включения копмьютеров по команде с телефона. Но не будем отвлекаться.)

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

А то сейчас делают "социальные сети" и представляют это как величайшее благо и революцию .А это - качание маятника в другую крайность - когда не клиент всё делает ,а сервер. Тут нужен баланс, для которого множество дублирующих и правящих серверов были бы полезны. Они же - основа более общей идеи о "неубиваемости" информации.

Я всё обстоятельно пояснил, без углубления в шелуху с вирусами и троянами?

Ладно, пусть будут описания страниц. Со стороны юзера: ты оставлял записки о сайте для себя? 
Я понимаю StumbleUpon, черезвычайно классная вещь, позволяет смотреть мне страницы которые люди похожие на меня находят интересными.

Теперь с технической стороны: зачем браузер? Прямо сейчас можно запустить application server на Javа, задеплоить свой вебсервис, что даст доступ до любых ресурсов компа, написать плагин к браузеру (к мозилле просто) и пользоват. Широко для всех это не пойдёт, просто не нужно... быть может только мне не нужно... 


В мелкософте прикручивая ActiveX к ИЕ тоже думали о светлом будущем, но дыры в безопасности by design (именно не баги, это дизайн системы такой с дырами изначально) убили идею на корню, сведя все ActiveX строго внутри сети и только если заказчик влюблёнными глазами смотрит только на мелкософт.

Я ищю слабые стороны идеи, т.к. это ИМХО самая важная инфа. А теперь перейдём к реализации: каковы результаты этого топа? хотя бы рекомендации.

Да, для себя, оргпометки.
Браузер - инструмент просмотра html, на котором написаны сайты. Оставляем браузеру браузерово.
Согласен, что слабые стороны надо искать. К слову, попытки постоянно прикрутить исполняемые модули к браузерам, которые не прекращаются и сейчас (виджеты), говорит, что такие модули нужны.

http://net.compulenta.ru/293438/ - "Разработчик Firefox планирует создать веб-операционную систему"



Вот, это та же идея на стадии реализации. Только поднятая до уровня ОС.

Другими словами, надо больше средств управления, чем есть у браузера. Не превращать браузер в ОС, а дополнить средства управления данными до работы с виртуальной ОС в компьютере. Разница в том, что они хотят централизовать управление на своём сервере. Этого делать не обязательно - любой из синхронизированных компьютеров может работать как сервер, в зависимости от того, какой из них подключён к сети.