Re: [d.love@dl.ac.uk: dynamic loading of native code modules]

[Thien-Thi Nguyen <ttn@giblet.glug.org>]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Wed, 24 Apr 2002 13:58:20 -0500

   For the time being, I think I had better respond to you on technical
   points if I think I can help, and limit my communications otherwise.
   The "Have you stopped beating your wife lately?"  communication
   strategy just makes me tired.  It makes work that would otherwise be
   enjoyable more of a chore.  OPMMV.

fair enough.  technically, there are several plug-in architectures in
existence to study from.  internal interfaces documentation is available
for some of them (typically, the good ones :-).  our job as a community
of guile programmers is to know guile well enough (including through
using guile) to be able to precisely describe our guile usage patterns
wrt other objects on the system.  these patterns most likely would be
influenced (in practice) by usage of these existing plug-in
implementations.

next, those who factor break down the patterns into attributes of the
general usage.  attributes may map to variables and procedures, which
are slammed into source by those who code, and explained thoroughly by
those who write about code.

this code and documentation is the toolkit and mini-language for
expressing an FFI.  it could be delivered alone as an "extensible
attribute mapping framework" or whatever.

interesting FFIs (ltdl, bfd, *.out, network streams, source in some vfs,
loopback dev, etc) can be expressed using this toolkit and (here's the
slackful part for maintainers :-) experimentation at that level is a
user concern and can be done completely in user land.  no worries, oop
ack!

for the purposes of bundled object libraries (aside from libguile),
guile itself uses the FFI api, in 1.4 or 1.6 or 1.8 or ... fashion, or
perhaps in the fashion of one of the users' creations.

so, this is what needs to be done to really put the active design phase
back in the users' hands and leave the maintainers w/ the core to tend,
for FFI.

bonus: this kind of process can run parallel w/ maintainers' own
experimentation w/ FFI architectures, which upon reflection, cannot be
called stupid because experimentation is a path w/ unknown ending (the
only stupidity would be not seeing this ;-).

to kick this off, can someone post an exhaustive summary of plug-in
architectures?  i will add that (and any further additions) under
workbook/ somewhere, no questions asked.

some seed attributes to think about:
 is-2-phase
 has-hook
 is-hooks-based
 depends-on-env-vars
 passes-through-env-vars-prefixing
 passes-through-env-vars-modifying-in-some-weird-way
 unloadable
 requires-system
 part-of-ABSTRACTION-PROGRAM-feature-list
 [your attributes here]

coders feel free to post code (if you know what you're doing :-).
everyone elese, please ask questions and point out flaws in the
approach.  i think we can get this ffi-toolkit api prepared and in use
for 1.8.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel