> From: Joe Wreschnig [mailto:piman / sacredchao.net]
> 
> Hi all,
> 
> I'm working on a Ruby module to parse/write to files in the 
> Linux /proc
> filesystem (ACPI interfaces), and I was wondering if there's 
> a preferred
> naming convention or namespace for things that are 
> OS-specific.

You're going to *write* to the /proc filesystem?!  Note that parsing /proc
won't be cross-platform at all.  Linux stores kernel info in /proc as flat
files but other flavors of *nix don't.  Solaris, for example, stores at
least some of the /proc data as binary data and you're expected to use a C
library function to get at the data.  This means that you're better off
writing this as an extension, unless you only care about Linux. :)

> The base
> module is going to be called ACPI, with objects like 
> ACPI::Processor and
> ACPI::Battery. Should I prepend something like System:: to ACPI? Or
> should I use something like Linux:: to be more specific? Or am I way
> off, and this stuff could go under the Kernel:: space (it seems to me
> that it doesn't fit with the rest of the code there)?

Have you seen some of the Sys:: modules that I have out on the RAA?  Rather
than create a separate namespace for each platform, consider using the trick
I used (which I borrowed from Dan Urist) with Sys::ProcTable.  In that
module, I let the extconf.rb file create a common file called "ProcTable.c".
That file is actually just a symbolic link to an os-specific file (linux.c
or solaris.c), depending on the platform you're building on.

Although the extensions behind the scenes vary greatly, those details are
hidden from the programmer.  If you're on Linux, the extconf.rb file uses
the linux.c and linux.h files.  If you're on Solaris, the sunos.c and
sunos.h files are used instead.  You end up with a single module, with a
single api.  

This approach let's you keep a single namespace, rather than one per
platform.  It also makes life easier for installation purposes.  I can
install a single, common package on any system and let the makefile do the
work.  It's also fewer files to maintain on your end.

Regards,

Daniel Berger