<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Colin,</div><div><br>On Jun 28, 2017, at 4:46 PM, Colin Putney <<a href="mailto:colin@wiresong.com">colin@wiresong.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 28, 2017 at 2:35 PM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">can you imagine how to fit "unknown" definitions into the design? That is, definitions that are not "understood" by this version of MC, but would still be preserved somehow, and stored with a new version. </div></div></div></blockquote><div><br></div><div>Good idea. </div><div><br></div><div>One thing we could do is make serialization into a more first-class concept, orthogonal to repositories. Then each serialization scheme would be responsible for creating "unknown" definitions if it reads something it doesn't recognize. Loading etc would ignore them, but the serializer would handle them correctly when reserializing. Some serializations might even be able to embed "foreign" unknown definitions - a binary serializer like Fuel or S&M could handle an MCUnknownChunkDefinition just fine, for example. But if not, we'd just drop the unknown definition just as we do now.</div><div><br></div><div>That would make the optimization you talked about before more legit—we can just copy bytes iff we know we're using the same serialization. </div><div><br></div><div>Another nice side effect of that would be to make repositories more flexible. We could use Content-Type headers, file extensions etc to figure out the right serialization scheme, instead of coupling file format to transport/storage mechanisms like we do now. </div><div><br></div><div>Does that make sense?</div></div></div></div></div></blockquote><div><br></div>Yes and it's very important.  This fixes a very nasty bug.  Anyone using Monticello to view Tweak packages will end up silently corrupted by those packages unless they happen to have the TweakMC package loaded.<div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Colin</div></div></div></div>
</div></blockquote><blockquote type="cite"><div><span></span><br></div></blockquote></div></body></html>