Re: More compatibility for refuse

[Greg Troxel <gdt%lexort.com@localhost>]

coypu%sdf.org@localhost writes:

I too was not happy about the notion that librefuse should be
deprecated.

> librefuse is matching the newer FUSE APIs. it's not matching the older.
> The filesystems want the older high-level API.

I have looked into this slightly.  I had the impression from the list
that filesystems/fuse had at any time a single high-level API revision,
and did not support backwards compat.  That, combined with an unstable
API, didn't seem like a good idea, since it imposes a duty of prompt
updating on all fuse clients and leads to a need for synchronized
updates.  I was wondering why, if that were true, it made sense for
librefuse to be more accomodating.

But, as I understand it now, filesystems/fuse has a default API and a
way for fuse clients to declare their API version.

I think you're suggesting that librefuse should have the same kind of
compatibility, at least for one rev back, via the same declaration.
Then we will have packages building cleanly with either, and not needing
to carry so many patches.  And librefuse will be a more complete and
thus better implementation of the family of FUSE APIs.  Did I get that
right?

If I did understand, that seems like obviously a good thing to happen,
and the only question is who feels like doing it.

> Or like ntfs-3g they mysteriously have duplicate code to use the
> lowlevel API. That can be avoided and still provide NTFS functionality
> (but no configure way to do it).

> We should provide a package with just the parts of ntfs-3g only using
> the high level FUSE API because other FUSE libraries also don't provide
> the low level API (like openbsd).

It would be nice to fix fuse-ntfs-3g to only use high-level API (perhaps
by default, if there's no really good reason to use the low-level API).
Ideally this would be fixed upstream.