[Mono-devel-list] Mono.Posix Structuring

[Jonathan Pryor]

On Fri, 2004-09-24 at 02:24, Todd Berman wrote:
> The only potential issue I see with this is existing code.
> 
> Considering that mono 1.0 is out, and that people are publishing
> software using these APIs, it would be nice not to break their stuff.
> 
> For existing, bound functionality, it would be great if we could
> maintain source and binary compatibility by keeping bound content where
> it is.

That's the joy of using new classes for the new functionality.  The old
class (Syscall) is still around, and can be used; it just will have
documented issues (only supports files <= 2^32 bytes, etc.).

New functionality goes into new classes, and when the new functionality
is stable, we deprecate the older classes, while still maintaining
them.  API and ABI compatibility is preserved.

Yay for versioning policies.

> It would be nice to keep this stuff as-is at least until the mono 1.1.x
> series has a real 1.2 release, and people don't have to track
> potentially both APIs (with the old stuff on the 1.0 branch and release
> line, and the new stuff on the 1.1 release line/HEAD).

As I mentioned above, HEAD could contain both.  We could remove the
older functionality in 2.0 or 3.0; it doesn't really matter (it'll just
be dead code, but still present).

The need to track both APIs is a potential downfall, but I don't think
too many people are tracking it now; for example, it's not possible to
fully implement a PosixStream wrapper with what Syscall currently has,
as fstat(2), fsync(2), and ftruncate(2) aren't present in Syscall.  (See
my earlier email that included a first-pass PosixStream wrapper.)

On the downside, moving to a different set of classes and a different
implementation would delay implementation of a complete Mono.Posix, but
given the lack of clamoring for support I've seen on mono-devel-list and
mono-list, that might not be a significant issue.

Plus, my approach solves real issues (Syscall isn't the most sensible
place to put all POSIX functions, and extended 64-bit support sanity).

 - Jon