[physfs] Multiple contexts in one process

[Sherief Farouk]

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.

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.

On Wed, May 16, 2018 at 10:06 PM Ryan C. Gordon <icculus at icculus.org> wrote:

> On 5/14/18 11:55 PM, Sherief Farouk wrote:
> > I made a small proof-of-concept implementation of this idea, which can
> > be found at https://bitbucket.org/sherief/physfs-ng-public - keep in
> > mind that it is both incomplete and incorrect in some aspects (no
> > per-context error code support for example) but for now it allows you to
> > have multiple contexts, each with their own search path(s) and write
> > path without (hopefully) breaking API backwards compatibility. For my
> > use case there is certainly value in having multiple components have
> > isolated PhysFS contexts inside a single process. Is there wider
> > interest in this feature? If so, it'd be nice to have it added to a
> > future version of PhysFS and maintained going forward - if not, I can
> > just keep a private fork and implement it there.
>
> This isn't something I'm personally interested in adding to PhysicsFS at
> the moment, but if it's interesting to you, definitely keep working on
> it and see where it takes you!
>
> If I were breaking backwards compatibility at some point, it might be
> nice to dump all the global state, and have the equivalent of
> PHYSFS_init() just return a handle/pointer that is used with every API
> call, which would solve this same problem (each handle would be a
> "context") but then again, the global state makes the public API more
> simple. I don't know. I'd have to think on it more.
>
> --ryan.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/physfs/attachments/20180516/caa1a74f/attachment.html>