From: Bill Stewart <stewarts@ix.netcom.com>
Date: Fri, 17 Nov 1995 18:46:12 +0800
To: Scott Brickner <sjb@universe.digex.net>
Subject: Re: NSA, ITAR, NCSA and plug-in hooks.
Message-ID: <199511170734.XAA12528@ix3.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


At 03:13 PM 11/16/95 -0600, Scott Brickner wrote:
>The problem is that the non-encryption program must use the same
>interface as the encryption program.  Text compression is often cited
....
>You'd need a program which not only *accepted* the additional parameter,
>but also *needed* the second parameter.  I confess I have some difficulty
>thinking of one.

If you support user-specified program/module interface which take
arbitrary string-valued arguments (e.g. Unix-style stuff or objects),
and you've got negotiation methods that can accept args,
then you've got a very general system which they shouldn't
be able to argue with - so the drop-in authors can hand the keys around
as 0xHEX-strings rather than bignums without the program needing to know.
Sorting and backup systems often want lots of options.

If you decide for reliability reasons to insist on registered module names,
to prevent problems like six different sorting modules with different
argument orders, or backup modules with different ideas of "original" and "copy"
(switching those two can be _Very_ annoying!), then there's even a mechanism
which the crafty foreigner to distribute modules and documentation!

>> An abstract set of open/modify/close
>> routines (where open returned a pointer to opaque state, say a session
>> key :) would be fine.

#--
#				Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com
# Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281