<div dir="ltr"><div dir="ltr">On Tue, Feb 10, 2026 at 7:24 PM Lance Andersen <<a href="mailto:lance.andersen@oracle.com">lance.andersen@oracle.com</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div><div>While I think there may be some merit/benefit to what your suggesting, I think we should take a step back and also look at ZipFS to see what we might be able to share as part of a refactoring as there is a somewhat similar flow to ZipFS initCEN</div>
<div><br>
</div>
<div>The benefit would be reducing the need to have to maintain somewhat duplicate code across both APIs.</div></div></blockquote><div><br></div><div>Lance,</div><div><br></div><div>I think discussing a reusable CEN parsing library at this point may be a bit premature. But we certainly don't want refactorings discussed here to make such a future harder to get to.</div><div><br></div><div>If your concern is that the refactorings suggested here may make ZipFile/ZipFS initCENs diverge further, then perhaps we can add as a goal that these two should be refactored together?</div><div><br></div><div>We could certainly do that. Either in lockstep with each refactoring being applied across APIs in the same PRs (where applicable), or we could clean up the ZipFile first, then have a follow up where we realign ZipFS at the end. Whatever we think makes most sense.</div><div><br></div><div>Wdyt?</div><div><br></div><div>Eirik.</div></div></div>