Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет dibr ([info]dibr)
@ 2009-09-09 23:19:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Фантом раз, фантом два...
     Я всё о Фантоме. Который "от dz".

     ОС Фантом настолько сурова, что в ней нет файлов. Документ, с которым в данный момент работает пользователь, даже в обычных операционках во время работы не "лежит на диске", а висит в памяти в виде пучка объектов. Система (Фантом), в силу, тсзть, дизайна, гарантирует долговременную сохранность состояния приложения (и, естественно, всей этой грозди объектов) - а раз так, то как бы нет потребности эту гроздь объектов переливать из одной формы (память) в другую форму (последовательность байт), и обратно. Привязали к этой грозди иконку на десктопе - пользователь кликает иконку, у него всплывает документ - красота, и никаких файлов!
     С точки зрения dz, отсутствие файлов, а равно и отсутствие необходимости чего-то куда-то сохранять, есть плюс разработчикам: не надо писать процедуру разборки "внешнего" формата "документа" во внутренний формат "как оно лежит в памяти", не надо писать обратную процедуру - сборки внутреннего представления в поток байтиков. И это как бы верно. Если бы не одно "но" - даже сам dz понимает, что без файлов, собственно, обойтись всё равно не удастся - мир вокруг, увы, слишком завязан на "одномерные потоки данных", и даже при передаче документа между двумя "фантомами" в промежутке может возникнуть какой-нибудь ужас, типа флэшки с FAT'ом, электрописьма с аттачем, или банального веб-сайта с пипкой "download". И тут-то файл и понадобится.
     Но это фигня! Если документ - не более чем "состояние приложения" (т.е. фактически множество объектов, принадлежащих приложению, плюс совсем чуть-чуть служебной информации, а может быть и без неё), то сохранение/загрузку документа можно сделать единообразным образом, и вообще поручить её системе: нужно сохранить документ - просим систему сделать "дамп состояния программы", нужно загрузить - просим "восстановить состояние из дампа". Дамп - обычный файл, который можно передавать куда надо, разработчику приложения думать ни о чём не надо - достаточно дёрнуть ровно одну ниточку в системе, а бонусом - вместе с документом при этом автоматом будет сохраняться всякая приятная мелочёвка типа undo-буфера и запомненных строчек в полях ввода. Недостатки тоже есть, но они решаемы :-)
     Есть только один нюанс. Для того, чтобы сохранять "гроздь объектов" - вовсе не нужен фантом. Никто не мешает приделать такую возможность к любому современному "объектно-озабоченному" языку. Более того - в принципе это приделываемо к любой программе, необязательно "объектно-ориентированной" - просто "объектом" там будет нечто другое. И мы поимеем один из бонусов фантома (заментый, правда, скорее разработчикам чем пользователям), не имея собственно фантома.

     Второй бонус Фантома (заметный пользователю, а не разработчику) - возможность "упасть-отжаться": прозрачное (без остановки приложений) постоянное "автосохранение" мгновенного слепка состояния системы (и приложений). Радость при этом в том, что даже при внезапном пропадании электричества - теряется не "вся работа с момента последнего сохранения", а только последние несколько минут, а то и секунд: после загрузки системы она восстанавливается по состоянию "на момент последнего снапшота". При этом для снятия снапшота, напомню, не требуется остановка приложений.
     Как это реализовано - особо не афишируется. Но, как мне кажется, особо фантазировать не получится. В момент начала снятия снапшота мы выставляем всем "объектам" флажок "не сохранён". Далее - бежим по всем объектам, сохраняя их, и сбрасывая флажки. Если приложение хочет изменить (записать в) какой-то объект, помеченный как "несохранённый" - система автоматически делает copy-on-write - дублирует объект, приложение начинает работать с объектом, а система, когда дело доходит до сохранения именно этого объекта, сохраняет копию (и убивает её - у нас остался оригинал). На самом деле всё чуть сложнее - снапшоты надо делать инкрементально (т.е. к объекту привязать что-то вроде dirty flag, и при его чистоте - не пересохранять объект, а делать ссылку "старая копия вполне годна"), снапшота должно быть два - один "в стабильном состоянии", второй "в процессе сохранения", а "флажки сохранённости" необязательно тупо переворачивать у всех объектов, достаточно в начале цикла сохранения переопределить их интерпретацию на противоположную. Впрочем, это подробности.
     Многие программы сами имеют функцию автосохранения. Полезную - когда документ небольшой, и жутко раздражающую, когда документ разрастается на сотни мегабайт и сохраняется минутами. Раздражающую ровно потому, что на время сохранения программа блокируется - действительно, сложно одновременно сохранять текущее состояние, и вносить в него изменения.
     Однако - опять вспомним фантом. Ничего не мешает делать фантомовское "прозрачное сохранение" в пределах одного отдельно взятого приложения. Механизм тот же - сохранение всего по кругу, CoW для несохранённых объектов при попытке их изменения, инкрементальность сохранения. После этого "автосохранение" в данном приложении начнёт работать волшебным образом: если я сижу и набираю текст (изменения - не более десятков байт в секунду) - автосохранение будет успевать сохранить изменения буквально в реальном времени, и только если я делаю большие изменения - автосохранение будет "отставать" на заметное время. В любом случае меньшее, чем обычное автосохранение всего документа "раз в пять минут", и не блокирующее на это время приложение. А заодно и обычное, не автоматическое, сохранение станет халявой: просто прекратили изменять документ, дождались конца цикла автосохранения, выдали окошко "всё ок" :-)
     Правда, есть нюанс: для достижения такого счастья в обязательном порядке понадобится поддержка со стороны языка программирования (среды выполнения, возможно даже системы). Поскольку, как мне кажется (могу ошибаться), на современных языках подобные извраты с CoW естественным образом не пишутся, а противоестественные методы - угробят идею в зародыше. Но, опять же, это возможно и без создания новой ОС - модернизацией уже существующих.

     Поэтому, я так подозреваю, где-нибудь в windows 8 или windows 9 мы вполне можем обнаружить "бессмертные" приложения или "прозрачное" сохранение. Файлы, надеюсь, останутся на месте: микрософт - не Завалишин, на такие радикальные меры не пойдёт :-)


(Читать комментарии) - (Добавить комментарий)


[info]dibr@lj
2009-10-18 16:30 (ссылка)
А ты на меня подписан что-ли - так быстро реагируешь? Если да - это подписка средствами ЖЖ, или средствами, скажем, яндекс-блогов?

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ilya_314@lj
2009-10-18 16:40 (ссылка)
На этот пост я трекинг ставил, кроме того еще RSS пл поиску в yandex блогах.

Технически можно обойтись без дефолтных значений. Например старый Word будет работать с документом через интерфейс IWord2003, а новый через IWord2007 и т.д. Собственно в COM это уже давно есть, только несколько тяжеловесно. В новых языках типа C# подобное делается очень легко, любой класс может реализовывать произвольный набор интерфейсов.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2009-10-18 17:06 (ссылка)
Насчет интерфейса не очень понял. Приношу я файл (сериализованное дерево объектов) на соседний компьютер, запускаю ворд, и?.. Скажем, новый ворд попросили загрузить файл от старого. Какой интерфейс он дёрнет, как этот интерфейс разберется со "старыми" объектами?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ilya_314@lj
2009-10-18 18:01 (ссылка)
Я думал немного с другой стороны и это не обдумал. Я просто предстваил как бы это выглядило в программе - мы из файла запрашиваем объект нужного типа и далее с ним работаем. Какие-то функции объекта возвращают другие объекты, которые и образуют этот самый граф.

Как работать в новой версии со старой и наоборот? Если открываем в старой, то видимо придется уметь преобразовать все объекты в объекты предудущей версии. Если концепция не претерпела существенных изменений, то можно просто использовать новые объекты которые могут выдавать интерфейсы старых, новые возможности мы соответственно не увидим, а старый код может не заметить. Однако может быть все не так просто, если меняли архитектуру - тогда просто так нельзя будет замаскироваться под старую сущность, ведь где-то поменялось поведение, какие-то объекты может совсем перестали существовать. А при использовании старой версии в новой придется всегда делать преобразование.

Кстати, а где должен быть весь исполняемый код объектов? Если в файле, то он может непомерно разрастись, представляешь код word в каждом документе! Нужно сериализовать только данные и привязываться в рамках глобального namespace (аналог GUID из COM) (многие проекты кстати приходят к необходимости подобного) к коду объекта, который может существовать в единственном экземпляре отдельно. Это наверное правильно, т.к. не превратит файлы в рассадник вирусов, код будет централизованно контроллироваться. Функции преобразования объектов разных версий тоже где-то находятся снаружи. Можно придумывать какие-то способы упростить миграцию, чтобы программисту было легче, но суть не поменяется, если меняется архитектура, то без копирования представления в старый/новый формат наверное не обойтись. В коммерческом софте часто начинают убивать COM интерфейсы старых версий через некоторое время или начинают блокировать некоторые функции, и это происходит не только от лени разработчиков, а из-за того, что старое слишком идет в разрез с новым.

Вобщем контроль версий всегда был проблемой и волшебного рецепта тут нет.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2009-10-18 18:27 (ссылка)
Код объекта, конечно, не в файле - нечего коду делать в "переносной" версии объекта.

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

Хотя, разумеется, на автомате совместимости не будет - программист всегда будет должен думать о совместимости в процессе написания. Просто обеспечить совместимость будет несколько проще.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ilya_314@lj
2009-10-18 18:44 (ссылка)
Согласен с тем, что упрощать эту часть нужно, но это все равно не снимает с разработчика заботу о совместимости.

Вспомни "dll hell" (http://en.wikipedia.org/wiki/DLL_hell). Одна из причин проблемы - казалось, что можно подменить код сохранив версию и все заработает. Оказалось, что в реальном мире все не так, даже если была ошибка, то лучше ее оставить, чтобы все не осыпалось. Каждой версии свой экземпляр кода, собственно это сейчас и сделано в папке WinSxS. Поэтому идея микса может быть несколько утопичной.

(Ответить) (Уровень выше)


(Читать комментарии) -