[CRIU] Images data format

[Kinsbursky Stanislav]

17.04.2012 18:10, Pavel Emelyanov пишет:
> On 04/16/2012 04:28 PM, Kinsbursky Stanislav wrote:
>> В личном разговоре с Павлом выяснилось, что произошло недопонимание.
>> Я предлагаю заменить (!) наш формат хранения и передачи данных, весь наш код по
>> дампу, рестору и показу имиджей иным, стандартизированным, форматом и чужими,
>> опенсорсными библиотеками.
>>
>> Зачем вообще что-то надо менять - уже описано.
> Еще пока нет. Попытка описания ниже :)

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

> Стас, это не так. Blobs vs text приспособлены для потоковой передачи одинаково. Либо
> ты как-то не так позиционируешь эту идею.

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

>> 2) Нам не придётся менять декодер в human readable, т.к. текущий формат вывода
>> плохо подходит для sed/awk и причих чудес.
> Текущйи как раз прекрасно подходит. One line per entry это лучшее, что можно иметь для
> подобных целей.

У нас нет стандартного вывода в human readable. И стандартного "ввода" обратно в 
binary тоже не будет.
Но так-то конечно. Мы может написать наши либы, которые будут гонять данные туда 
и обратно.
Их, правда, придётся поддерживать.

>> 4) Нам не придётся писать.сопровождать библиотеки под свой формат для сторонних
>> пользователей, которые, скажем, задумают строить свои фильтры/конвертеры между
>> suspend/restore. Нужен будет только наш словарь.
> Нам в любом случае никаких библиотек не придется иметь. Идея в том, что если у тебя
> есть конвертер из human readable в internal и обратно, то больше ничего не надо.

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

>> 5) Нам/сторонним разработчикам будет с дальнейшем легко расширять CRIU новыми
>> объектами, не заботясь о том, как выводить и сериализовать эти данные.
> Вот тут я тоже не уверен. Can you elaborate on this?

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

-- 
Best regards,
Stanislav Kinsbursky