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

пардон за тормозной постинг.

S>Эмм, реализация всех фич требует дополнительных усилий. При этом некоторые вещи легко и дёшево делать на десктопе, а некоторые — легко и дёшево делать в вебе.

Фичи имеют приоритеты. Для многих SPA и десктопных поддержка синхронных копий наверняка вообще не рассматривается? для Гугль докс это, наоброт, очень важная, изначально запроектированная функция.

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

S>Во-первых, ничего страшного в "тяжёлых" данных нету. Вот у меня мейлбокс в лучшие годы занимал 30GB. Мешало ли это аутлуку показывать его одновременно в двух окнах? Нет, не мешало.

Почтовый клиент все же держит в памяти не все 30Гб, а небольшое "окно". Я говорил о приложениях, которые работают с большими данными полностью в памяти. Подобия упоминавшихся Фотошопа и 3д редакторов в веб уже есть.

S>Во-вторых, вовсе незачем держать целую отдельную копию всего приложения. Речь идёт всего лишь о том, чтобы иметь два параллельных view одних и тех же данных.

С разными view понятно. Я говорю о копиях, потому что топик начался с нового таба, который для SPA копия.

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

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

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

S>Нет никаких интересных горизонтов для безопасности веб приложений. Веб приложения всю жизнь умели работать в многих копиях. Чтобы это поведение сломать, нужно принимать специальные меры в разработке приложения.

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

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

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

пардон за тормозной постинг.

S>Эмм, реализация всех фич требует дополнительных усилий. При этом некоторые вещи легко и дёшево делать на десктопе, а некоторые — легко и дёшево делать в вебе.

Фичи имеют приоритеты. Для многих SPA и десктопных поддержка синхронных копий наверняка вообще не рассматривается. для Гугль докс это, наоброт, очень важная, изначально запроектированная функция.

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

S>Во-первых, ничего страшного в "тяжёлых" данных нету. Вот у меня мейлбокс в лучшие годы занимал 30GB. Мешало ли это аутлуку показывать его одновременно в двух окнах? Нет, не мешало.

Почтовый клиент все же держит в памяти не все 30Гб, а небольшое "окно". Я говорил о приложениях, которые работают с большими данными полностью в памяти. Подобия упоминавшихся Фотошопа и 3д редакторов в веб уже есть.

S>Во-вторых, вовсе незачем держать целую отдельную копию всего приложения. Речь идёт всего лишь о том, чтобы иметь два параллельных view одних и тех же данных.

С разными view понятно. Я говорю о копиях, потому что топик начался с нового таба, который для SPA копия.

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

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

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

S>Нет никаких интересных горизонтов для безопасности веб приложений. Веб приложения всю жизнь умели работать в многих копиях. Чтобы это поведение сломать, нужно принимать специальные меры в разработке приложения.

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

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