> how do components/plugins ease code re-use?
> surely they are all the same as using dlopen and a function call?
A couple of things here:
plugins often seem to imply some software which displays
something (i.e. a sub-window). Another sense of a plugin that
I see is much more dependancy on the calling environment
than you would normally expect from a shared library. (E.g. expecting
functions in the caller to be present, c.f. Apache modules, GIMP
plugins etc.)
In a sense you have a blob of functionality, and you draw a line
somewhere in the middle, some functionality on one side, some on the
other. You want to make the strings crossing the line minimal, sensible
and optimal. A partitioning problem.
>either way you have to have an agreed function name, arguments and
>return value. the only way of really avoiding that is something like
>what perl does, by autoconverting ints/strings and allowing hashes of
>argument pairs to be passed(*).
Some of this is what I think is 'agreed names'. It seems to
be not so much a fixed name, but you search for a target that
fulfills a name. Complicated stuff, but is it neccesary? CORBA
has lots of this.
converting parameters and structures is what some people call
marshalling, which is the stuff of the gourd and the sandal.
Hence XML folk have RPC data in XML format. There are endless other
varieties. My current personal favorite is a thing called
sexp, invented by Rivest of MD5 and encryption fame. Looks like
lisp data.
Small manifesto atteched at end, for the interested.
>(this is, of course, assuming that binary compatibility isn't
>important.. and, well, it isn't)
Not sure of what your getting at here...
Jamie
--------------------------------------------
Here are the design goals for S-expressions:
-- generality: S-expressions should be good at representing arbitrary
data.
-- readability: it should be easy for someone to examine and
understand the structure of an S-expression.
-- economy: S-expressions should represent data compactly.
-- tranportability: S-expressions should be easy to transport
over communication media (such as email) that are known to be
less than perfect.
-- flexibility: S-expressions should make it relatively simple to
modify and extend data structures.
-- canonicalization: it should be easy to produce a unique
"canonical" form of an S-expression, for digital signature purposes.
-- efficiency: S-expressions should admit in-memory representations
that allow efficient processing.
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
