<div>Mods and scriptable components having multiple filesystem “namespaces” is my current use case. It’s especially essential for tools more than the actual engine / runtime. </div><div><br><div class="gmail_quote"><div>On Fri, May 18, 2018 at 01:03 Francesco Bertolaccini <<a href="mailto:bertolaccinifrancesco@gmail.com">bertolaccinifrancesco@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I don't have a specific use case right now, but I can imagine it being very useful if, for example, a game wants to use PhysFS both for general IO and for sandboxing stuff like user mods, so that the engine has access to the whole tree while mods are only allowed to look at their own data<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 18, 2018 at 9:26 AM, Sherief Farouk <span><<a href="mailto:sherief.personal@gmail.com" target="_blank">sherief.personal@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>That's how this branch currently implements it - so far everything is backward compatible, I was just surprised by Ryan's comment and was wondering whether he'd ever consider a non-backwards-compatible future path. I currently have no plans to suggest changes that break backwards compatibility - if it comes to that I think a fork would be better. I'm curious to hear whether you have a use case for this feature.</div><div class="m_-6086995452744273937HOEnZb"><div class="m_-6086995452744273937h5"><br><div class="gmail_quote"><div>On Thu, May 17, 2018 at 9:33 PM Francesco Bertolaccini <<a href="mailto:bertolaccinifrancesco@gmail.com" target="_blank">bertolaccinifrancesco@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>What if backwards compatibility was provided by keeping a default global context that can be accessed through the current API, but actually acts as a thin wrapper around the new reentrant interface?</div><br><div class="gmail_quote"><div>Il ven 18 mag 2018, 06:25 Ryan C. Gordon <<a href="mailto:icculus@icculus.org" target="_blank">icculus@icculus.org</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br><br>> At what point would you consider giving a solid yes / no to whether this <br><br><br>> is welcome as a future feature to PhysFS? If I don't need to maintain <br><br><br>> backwards compatibility I can move faster and implement a leaner API, <br><br><br>> though a complete fork is something I usually prefer to keep as a last <br><br><br>> resort.<br><br><br><br><br><br>I'm definitely not interested in breaking backwards compatibility, and <br><br><br>I'm not sure I'm interested in the feature in general, either.<br><br><br><br><br><br>--ryan.<br><br><br><br><br><br><br><br><br>_______________________________________________<br><br><br>physfs mailing list<br><br><br><a href="mailto:physfs@icculus.org" rel="noreferrer" target="_blank">physfs@icculus.org</a><br><br><br><a href="http://icculus.org/mailman/listinfo/physfs" rel="noreferrer noreferrer" target="_blank">http://icculus.org/mailman/listinfo/physfs</a></blockquote></div><br><br></blockquote></div><br><br></div></div></blockquote></div><br></div><br><br></blockquote></div></div>