[Gllug] Introduction (not really relevant to anything, just saying hello)

[Russell Howe]

Nix wrote:
> On Wed, 23 Jun 2004, Russell Howe moaned:
> 
>>It'd be like having a network-enabled IDE driver - not necessary when
 >>a higherlevel abstraction lets you do what you need to (nbd). In this
 >>case, esd/aRts/... are the higher (userspace) level abstraction.
> 
> 
> This would be a reasonable position if the higher-level abstraction didn't
> throw most of the capabilities away :(

Always the problem with abstract interfaces - how to hide the dirty work 
of the underlying implementation whilst still allowing the callers to 
make use of desirable implementation-specific features. How to 
generalise without becoming so general as to be useless? Does 
abstraction have to amount to generalisation at all?

Just out of interest, what methods do people know of for doing this? 
Surely it has to be one of the classic design problems in programming?

These are the ones which I can come up with off the top of my head:

* Do nothing. Provide an abstraction of common functionality, with 
possibly a way to interface directly to the implementation underneath 
for those callers who want to do more.
* Make your abstraction have an extendible method of advertising 
extensions to the common feature set. I think IMAP has a way for a 
client to ask the server "What commands do you support?". Does this 
really differ from the above?
* Make your abstraction the superset of all implementations, and where 
an implementation is lacking, emulate the functionality. Things like 
graphics libraries spring to mind - software emulation for features not 
present in hardware.

Things like DirectX and OpenGL spring to mind as examples of the latter, 
but I know that OpenGL (at least) also has some aspects of the former, 
whereby you can get a list of supported extensions.

These 3 (2?) methods seem quite obvious, and each leads to problems - 
the first one leads to callers needing to know about proprietary 
implementation-specific details, possibly with multiple implementations 
having similar extensions, all doing a similar thing in different ways.

The latter method can be seen as limiting functionality to only that 
which is defined in the original abstraction, which could lead to the 
spec. being considered too limiting and be seen as encouraging 
proprietary solutions.

The second method could be seen as different to the first if it involved 
some kind of standards body, which oversaw extensions to the 
abstraction, allowing for the abstraction to evolve gradually as new 
requirements appeared.

Sorry about the number of times I said abstraction, but I wanted to keep 
it, well, abstract. I didn't want to say "protocol" or "API", since this 
kind of problem can probably be seen in many places, and the solutions 
are probably mostly generally applicable.

This must've been a problem before computers were around, so does anyone 
know of any 'classic' solutions to this? "Back in Plato's day, when I 
were a lad..."

-- 
Russell Howe
rhowe at siksai.co.uk
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug