Why not to use implement functionality using X mechanisms

[Richard Frith-Macdonald]

OK, this is about the pasteboard ... but the 'X' in the subject equally 
applies to various
other platform specific functionality, so the 'X' could actually be the 
algebraic 'x' for
unknown.

OpenStep was originally supposed to a cross-platform system designed to 
insulate the programmer
and user from system dependencies (though commercial realities forced 
NeXT to drop this radical
approach and concentrate on the modest one of making it a system to help 
programmers port apps).

I believe that this aim is one that GNUstep inherited, and I certainly 
did ... The developers
of GNUstep certainly put quite a lot of thought into making it as 
portable and flexible as
possible, and trying to make it simple/consistent so that it's easy to 
port ... we *do* want
to eventually run on many platforms.

So, if there is a practical, portable way to implement required 
functionality, we should always
implement that mechanism rather than using a platform specific one.

One of the biggest factors (probably *the biggest*) in determining what 
is 'practical' is the
fact that we are a small development team, with a huge task.  So we 
always have to be very
careful to spend our time effectively.  We need to keep the codebase as 
small as possible
with as little system specific code as possible, so we can maintain and 
port it.  If we
implement OpenStep functionality using platform specific code, we are 
effectively locking
ourselves into that platform.  If on the other hand, we use generic 
code, there is no such
lockin.
When it comes to communicating with other non-GNUstep systems, we 
sometimes have to use the
platform specific code compatibility code.  In this case it makes sense 
to -
1. Use as little platform dependent code as possible (keep the codebase 
small)
2. Implement generic code first and add the compatibility code as an 
optional extra (avoid lockin)

Now, we have to be particularly careful about the X-window system ... 
since there really is no
alternative platform yet, anything that makes GNUstep apps work better 
in an X environment
will be used by everyone and will be supported at the expense of generic 
mechanisms, thus
locking us even more into X.  So we need to do our utmost to make sure 
that we implement these
improvements in a generic way.

People are working on getting the gui stuff running in Windows-NT ... 
if/when that is done and
windows users start really playing with GNUstep, I imagine the problem 
will become much more
severe, but it will be dependency on microsoft specific code we will be 
fighting to avoid.
On the other hand, having real competition between X and windoze systems 
might encourage us to
write generic code  ... I really hope so.


Back to the pasteboard ... recent discussions have highlighted two 
flaws -

1. The appkit doesn't know about remote hosting, so doesn't currently 
connect to the correnct
pasteboard server when you use the X specific DISPLAY environment 
variable to get the app to
display on a remote host.  Actually, this is not limited to the 
pasteboard.  the gui layer
won't handle workspace interaction properly either.  However, this is 
all simple to fix and
I'll probably add a -NSHost command line option to do it soon.

2. There is a theoretical situation where two GNUstep apps run on 
separate hosts which have no
network connection between them, and display on a third host which won't 
run the pasteboard
server.  In this case pasteboard operations can't work using the GNUstep 
pasteboard server
directly, but would work using the X-clipboard, because the X server 
would mediate the
communications between pasteboard servers used by the apps.  So here our 
implementation would
be very inefficient.

Normally, I'd say that if someone was willing to implement an contribute 
a native implementation
of some functionality to supplement a generic mechanism, that would be 
great.  In this case I
think that the benefit is so small that any such work should be 
discouraged, and adding such
a thing to the codebase might even be more of a maintenance liability 
than it's worth.

PS. This does not apply to use of the drag-and-drop clipboards, in this 
case the complexity of
integrating the X mechanisms into generic code is higher than that of 
writing a relatively
standalone X implementation in the backend, so here we are pretty much 
forced to use the
native clipboard mechanism directly, and only referring to the 
pasteboard server for DnD
of complex/large items of data being transferred between GNUstep apps.