[CRIU] Images data format

[Pavel Emelyanov]

On 04/17/2012 06:35 PM, Kinsbursky Stanislav wrote:
> 17.04.2012 18:10, Pavel Emelyanov пишет:
>> On 04/16/2012 04:28 PM, Kinsbursky Stanislav wrote:
>>> В личном разговоре с Павлом выяснилось, что произошло недопонимание.
>>> Я предлагаю заменить (!) наш формат хранения и передачи данных, весь наш код по
>>> дампу, рестору и показу имиджей иным, стандартизированным, форматом и чужими,
>>> опенсорсными библиотеками.
>>>
>>> Зачем вообще что-то надо менять - уже описано.
>> Еще пока нет. Попытка описания ниже :)
> 
> Это я вообще не понял. Не понятно ни чему ты возражаешь, ни чего там ещё за 
> попытка есть ниже...
> 
>> Стас, это не так. Blobs vs text приспособлены для потоковой передачи одинаково. Либо
>> ты как-то не так позиционируешь эту идею.
> 
> Опять  я не понимаю, о чём ты говоришь.
> По мне формат, приспособленный для потоковой передачи, должен обладать как 
> минимум следущим свойством:  тип и размер объекта отпарвляются до самого объекта.
> Текущий формат храния данных в CRIU не обладает таким свойством.

ACK. В таком виде аргумент принят.

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

Если вывод и ввод это printf и scanf, we can live with it, правда?

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

Еще раз, если под либами ты имеешь в виду libc-шный printf/scanf, то это не issue.

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

Да, этот use-case валиден. Фильтрация on-the-fly.

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

Как это будет выглядеть с protobuf-ом?

Thanks,
Pavel