seventh guardian wrote:
On 8/23/06, Jacob Bachmeyer <[EMAIL PROTECTED]> wrote:
As a possibility for 3.0, could the module interface be reworked perhaps
more extensively?
I had an idea for an ICE-based module interface that would, if well
done, be more flexible and extensible than the current system.
(It's biggest change would be that modules would no longer need to be
children of the fvwm process.)
It could solve this problem by defining a "query-flag" operation, with
an upward-compatible way of specifying flags.
FVWM already links libICE (session management uses it), so this wouldn't
add much to the size of the running process.
Is the time right to start discussing major changes for 3.0, or should I
hold this a while longer?
This may not be the right time to start the "final" discussion, but I
guess no one will complain about us "spaming" the fvwm mailing list :P
As for this discussion, IMHO the best thing to do first is to abstract
ourselves from the actual communication method. We first define an
interface over a generic bidirectional stream, then we can implement
it over any kind of mechanisms. Being it pipes, ICE, DBUS, dynamic
loaded libraries, TCP/IP.
If we manage to work out a good abstract interface, it wouldn't be
hard to implement it using ICE..
I was thinking of using the ICE opcodes in a meaningful manner. A
packet-oriented interface, rather than a pure stream, in other words.
Since ICE should be available on any system where fvwm is in use, why
worry about other mechanisms? (Or am I wrong here?)
ICE can use TCP/IP as its transport, so using ICE would give us network
transparency if we want it.
Dynamic linking into fvwm would mean that a poorly written module could
crash fvwm, but it shouldn't be too hard to construct a "dynamic shell"
module that loads an .so and then uses the ICE interface to communicate
with fvwm. (Why anyone would want this is another matter.)
A similar shell could provide backwards compatibility for older modules.
A DBUS interface could be implemented in a similar manner, if a
reasonable way to represent fvwm's state to DBUS is devised. This could
actually be used in an even more general manner--interface modules could
be written for KDE's DCOP and whatever GNOME uses as well.
Using ICE would allow us to have one interface in fvwm proper and then
have other interfaces atop that one in modules that can be started by
the programs that need them.
Also, ICE is intended for use underneath an app-layer library. This
could help with maintaining the module interface code if we put it in
such a library.
ICE's protocol is similar to X's, which might also help maintainability.
To sum up, ICE presents a (almost) ready-made command-response
interface--all we do is define the opcodes and implement the ends. And,
if session-management is compiled in, libICE is already in use for that,
so we can remove the module interface's transport from fvwm's code and
use libICE.
Is there something so wrong with ICE that working from scratch rather
than using it to abstract the transport is a good idea?
