[Mono-dev] Mono.Unix Future Directions, Questions

[Jonathan Pryor]

Miguel noticed yesterday that Mono.Unix currently has over 270
[Obsolete] declarations.  Things will be changing soon, so here is the
what, why, and questions about possible future changes (see the end for
questions under consideration -- feedback is appreciated).

Mono.Unix was originally conceived as a "proper" wrapping over POSIX,
correcting many of the issues that Mono.Posix had regarding enumeration
handling (i.e. it only had a unidirectional mapping but was using it as
if it were bidirectional), providing a stable ABI (use "ulong" for
size_t instead of "uint" or "UIntPtr" to be portable between ILP32 and
LP64 systems), and being closer in spirit to POSIX
(Mono.Posix.Syscall.GetHostName?).

Mono.Unix then provided high-level wrapper classes such as UnixStream
for better integration with the rest of the .NET framework.

Unfortunately, both of these were placed into the same namespace, so if
you just have a `using Mono.Unix;' statement, there are over 100 types
available, and from browsing Monodoc the most "interesting" types don't
show up until the 36th entry in Monodoc (because lots of helper structs
and enumerations show up first alphabetically).

For this and other reasons, I'm splitting Mono.Unix up into two
namespaces: Mono.Unix for the high-level types, and Mono.Unix.Native for
the low-level types.  See this for more information:

	http://www.jprl.com/Blog/archive/mono/2005/Sep-20.html

The namespace split isn't the only change.  I've been reviewing the
current Mono.Unix API, and will be making a number of changes after the
next release, for the following reasons:

  - CLS Compliance: CLS compliance is now a goal for Mono.Unix, which 
    requires that a number of types change.  For example, User IDs (uid)
    and Group IDs (gid) will become `long' (currently they're uint).
    Not all members will be CLS compliant -- there will be a number of 
    members explicitly present to provide a bridge to Mono.Unix.Native,
    so 100% CLS compliance isn't possible -- but it will be better than 
    today.

  - Consistency: members returning ID types (pids, uids, gids, etc.) 
    aren't always immediately apparent.  For example, what's the type 
    of UnixEnvironment.User?  Previously it was uint, which isn't 
    particularly helpful.  It's been [Obsoleted] by RealUserId, which
    makes it clear that it's a uid, and a RealUser property will be
    added which returns a UnixUser instance.  The same will be done for
    UnixFileSystemInfo.OwnerUser (added OwnerUserId for the uid, and 
    after the next release OwnerUser will return a UnixUser instance, 
    not a uid).

  - Complexity: I was apparently on crack for some things, like the 36
    methods in UnixFile for AdviseNormalAccess(), 
    AdviseSequentialAccess(), AdviseRandomAccess(), AdviseNeedAccess(),
    AdviseNoAccess(), AdviseOnceAccess(), and their overloads.  These
    have been replaced with methods taking an enumeration.  Originally
    I was trying to avoid adding new enumeration types, but I now view
    avoiding them as a mistake.

After release 1.1.10, I will be changing any [Obsolete] members which
need to have their return/property type changed.  Anything that exists
purely as overloads may live longer, but most [Obsolete]s should be
removed by 1.2.  The types in Mono.Unix/Syscall.cs and
Mono.Unix/Stdlib.cs will be stay for 1.1.11 (if it exists), but will be
removed for 1.1.12 or 1.2 (whichever comes first).

Questions:

1.  For UnixFileSystemInfo, I "split up" FilePermissions (Unix mode_t) 
    into 3 sub-parts: FileTypes (directory, regular file, etc.), 
    FileAccessPermissions (UserRead, GroupRead, etc.), and 
    FileSpecialAttributes (SetUserId, SetGroupId, Sticky).

    Should FileSpecialAttributes be separate, or should it be part of 
    FileAccessPermissions?

2.  Do I really need so many wrapper classes?  UnixFile, UnixDirectory, 
    UnixGroup, and UnixUser are all wrappers over their associated 
    XxxInfo types, and most of their methods are effectively:

	public static RetType GetSomething (Foo foo)
	{
		return new XxxInfo (foo).Something;
	}

    I did this because that's what System.IO does, but (1) it's a lot
    of duplication, and (2) I see that Microsoft didn't continue this
    practice for System.IO.DriveInfo (there is no System.IO.Drive, 
    at least not the last time I checked).

    Would anyone object to my removing these wrapper types, and move the
    useful static methods into the associated XxxInfo classes?

    I think this would help with the API cleanup, as there'd be fewer
    classes to look at (and document!).

 - Jon