Patches and forking (was RE: VNCrack)

[Allan C.]

Hey guys.  I'm hearing these options passed around which seem to
hinge on one basic assumption: You must decide on your options at compile
time only.

>From that basic assumption, it seems there are two approaches to take.

Roll-your-own: Assume the user has a compiler and some expertise. The user
chooses his/her options in the process of creating a _static_ binary.
(Example from my experience: Older Linux Kernels)

Pre-made binaries: Try to guess what various options users might want, and
compile a variety of binaries with different sets of options.
(Example from my experience: Eudora Lite and Eudora Pro)

...But what about deciding at run-time? (A slight misnomer, as the
user doesn't need to choose the options every time he/she runs the program.)

A simple example is 'PINE', the email reader I use. It can hide
or expose options depending on a config file. However,the size of the binary
or footprint doesn't change in the case.

Netscape Communicator and Winamp (MP3 Player) are better examples.
With those, you have the option for plugins.  I don't know exactly how
they work, but I assume someone can write a new plugin for Netscape according
to a given spec, without consulting programmers in Mountain View.

Another example: The recent Linux Kernels have many features which can be
Loadable Modules.  I don't know exactly how this all works, but here's my
best guess. 

You'd create a DLL (or .so file). Let's say it's called encryption.dll.
But instead of having all the necessary code, it is just a tiny file
with nothing but 'stub' code. They take and return the same
number of parameters, but simply return a 'feature unimplemented'
return code.

The user can then optionally replace that library file with the real
one, if they want encryption to work. The real library file may be
as larger (even bloated) as necessary.

Is this not a happy medium? Now, I understand Communicator may not be the
best example.  Weighing in at around 23MB without plugins, it certainly
has made it to 'bloated' status.

However, I used to work at Netscape Communications. When I did, I heard
about future plans for a browser that would fit on a 1.44MB floppy and
wouldn't do much besides render HTML. The javascript interpreter,
JPEG viewer, JVM, etc. would be included as seperate plugins.

Apparently, this plan died somewhere inside the AOL bureaucracy,
however I think the idea is solid.

Of course, I know so little about the VNC code, I have no idea if this would
be prohibitively complicated to implement.

But isn't it (at least in theory) a viable alternate to compile-time options?

--Allan
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at" uk.research.att.com
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------