Date: Fri, 14 Jul 2023 10:08:19 -0800 From: Rob Wing <rob.fx907@gmail.com> To: Matthew Grooms <mgrooms@shrew.net> Cc: virtualization@freebsd.org Subject: Re: BHYVE SNAPSHOT image format proposal Message-ID: <CAF3%2Bn_cc5ZpGsKCff%2Bu-rSjnJn%2BN1jdu9KW0Y5b6n_TieMsfng@mail.gmail.com> In-Reply-To: <79fabe94-b800-c713-48ea-518da1f74e4d@shrew.net> References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> <6b98da58a5bd8e83bc466efa20b5a900298210aa.camel@FreeBSD.org> <8387AC83-6667-48E5-A3FA-11475EA96A5F@gmail.com> <d92db9bfbea181d6eb9d57b579d67e8e118ef4de.camel@FreeBSD.org> <986A83D8-E0E0-4030-9369-A5B3500E27C6@gmail.com> <79fabe94-b800-c713-48ea-518da1f74e4d@shrew.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Fri, Jul 14, 2023 at 9:40 AM Matthew Grooms <mgrooms@shrew.net> wrote: > > I see a need to define a format for bhyve so it's possible to mix > different sections and encodings inside a unified stream. But all the > data in your nvlist example above can be easily be represented as text. > We already have JSON, YAML, XML, etc ... By adopting an preexisting > format, we could retain the snapshot structure instead of lifting it up > into the stream format. Even if we decide to break the structure up into > different nvlist stream sections, using a common format would allow > other tools to more easily parse and validate the structure inside these > sections. Isn't that a good thing? Is there a reason we're trying to > reinvent the wheel here? > Does JSON support storing binary data? I'm under the impression that it does not. [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 14, 2023 at 9:40 AM Matthew Grooms <<a href="mailto:mgrooms@shrew.net">mgrooms@shrew.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> I see a need to define a format for bhyve so it's possible to mix <br> different sections and encodings inside a unified stream. But all the <br> data in your nvlist example above can be easily be represented as text. <br> We already have JSON, YAML, XML, etc ... By adopting an preexisting <br> format, we could retain the snapshot structure instead of lifting it up <br> into the stream format. Even if we decide to break the structure up into <br> different nvlist stream sections, using a common format would allow <br> other tools to more easily parse and validate the structure inside these <br> sections. Isn't that a good thing? Is there a reason we're trying to <br> reinvent the wheel here?<br></blockquote><div><br></div><div>Does JSON support storing binary data? I'm under the impression that it does not.<br></div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAF3%2Bn_cc5ZpGsKCff%2Bu-rSjnJn%2BN1jdu9KW0Y5b6n_TieMsfng>
