<div dir="ltr"><div>Would you ever accept a PhysFS 4.x that breaks backwards compatibility? I've been working on this with the intent of making it possible to merge it into the main PhysFS tree, so I don't break backwards compatibility and that introduces some complexity. Right now an old app using PHSFS_init() will share a global context object, and so do all API calls that don't specify an explicit context.</div><div><br></div><div>At what point would you consider giving a solid yes / no to whether this is welcome as a future feature to PhysFS? If I don't need to maintain backwards compatibility I can move faster and implement a leaner API, though a complete fork is something I usually prefer to keep as a last resort.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, May 16, 2018 at 10:06 PM Ryan C. Gordon <<a href="mailto:icculus@icculus.org">icculus@icculus.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 5/14/18 11:55 PM, Sherief Farouk wrote:<br>
> I made a small proof-of-concept implementation of this idea, which can <br>
> be found at <a href="https://bitbucket.org/sherief/physfs-ng-public" rel="noreferrer" target="_blank">https://bitbucket.org/sherief/physfs-ng-public</a> - keep in <br>
> mind that it is both incomplete and incorrect in some aspects (no <br>
> per-context error code support for example) but for now it allows you to <br>
> have multiple contexts, each with their own search path(s) and write <br>
> path without (hopefully) breaking API backwards compatibility. For my <br>
> use case there is certainly value in having multiple components have <br>
> isolated PhysFS contexts inside a single process. Is there wider <br>
> interest in this feature? If so, it'd be nice to have it added to a <br>
> future version of PhysFS and maintained going forward - if not, I can <br>
> just keep a private fork and implement it there.<br>
<br>
This isn't something I'm personally interested in adding to PhysicsFS at <br>
the moment, but if it's interesting to you, definitely keep working on <br>
it and see where it takes you!<br>
<br>
If I were breaking backwards compatibility at some point, it might be <br>
nice to dump all the global state, and have the equivalent of <br>
PHYSFS_init() just return a handle/pointer that is used with every API <br>
call, which would solve this same problem (each handle would be a <br>
"context") but then again, the global state makes the public API more <br>
simple. I don't know. I'd have to think on it more.<br>
<br>
--ryan.<br>
<br>
<br>
</blockquote></div>