On 2/2/06, Dominik Vogt <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 01, 2006 at 02:58:27PM +0000, seventh guardian wrote:
> > Hi.
> >
> > First of all, there's a minor bug in libs/Module.h: the funcion
> > SendFinishedStartupNotification() is declared twice (on lines 147 and
> > 166).
> >
> > With that asside, I'm writing a module for Fvwm to support the xorg's
> > Xevie extension. I really don't like to reinvent the wheel, so I'm
> > creating it inside the building tree, using Module.h and other helping
> > libs. (that's the reason why I found that bug).
> >
> > I also found that there's a nice parsing function which is rarely used
> > by any of the other modules, ParseModuleArgs().
>
> Actually it is not used at all.
>
> > It returns a struct
> > with the module args, including the two communication pipes. The
> > problem here is that the structure itself is "strange" to use, because
> > the other all the other functions genericaly require a pipe array,
> > fd*, with the first element as transmit pipe and the other as a
> > receive. So there are two alternatives here.
>
> Um, I can't think of any function that needs a pipe array in any
> module or the module library. Can you give examples?
>
void GetConfigLine(int *fd, char **tline)
{
(.....)
SendText(fd, "Send_ConfigInfo", 0);
(.....)
packet = ReadFvwmPacket(fd[1]);
}
> > Either to ALLWAYS pass
> > them the to_fvwm pipe, which works because of their order in the
> > struct (but makes the code a little cryptic, like "Receive(to_fvwm)"),
>
> There is no guarantee that this works.
>
> > or to copy them to an array fd[2], which uses twice as much memory
> > (not a real problem most of the times, but definitelly a bug).
>
> > With that said, my suggestion is this: to use a struct to store the
> > interface data (file descriptors, name, etc) and to make the functions
> > use that struct instead of the particular elements.
>
> But ParseModuleArgs already allows this. It parses the module
> arguments and passes back a structure that contains the number and
> an array of options not yet parsed. It's easy to write more
> parsing functions with this information, but it's actually not a
> very good idea because modules should be configured by the config
> file, not the command line (with some exceptions).
>
Yes, I know. But now functions rely on having two pipes and read/write
on them in a raw way. Having a proper (more complete) struct and
functions to work with it would make the code actually independent of
the real interface. Modules could communicate by TCP/IP and the module
wouldn't notice it at all (hum can't see the advantage of that, but I
guess you got my point).
> > That way more
> > helper functions would come up, such as a function that requests the
> > config info and calls a user defined parsing function to handle the
> > lines as they come up. Or a function to wait on the pipe for packets
> > and also passing them to a user defined parsing function. Having a
> > struct instead of scatered global vars makes that task easyer, as they
> > are all passed at once inside the struct.
> >
> > Also, that way if someday (fvwm 3 maybe?) the module interface
> > changes, the modules themseves woudn't need to change that much.
>
> The module packet interface changes once in a while, but I don't
> see the command line changing anytime soon.
>
> > It
> > woudn't be that difficult to change the current modules to use the new
> > functions. Besides, all already compiled modules would work without
> > any change, and unofficial ones would compile perfectly as long as
> > they don't use the new Module.h. Also there could be an "adaptation
> > time" where both libs were supplied..
> >
> > Those were my thoughts. Please comment..
>
> Streamlining the module interface code is definitely worthwhile.
> It's just that there are so many modules and so much work to do.
> The first step would be to just *use* ParseModuleArguments
> everywhere (without breaking all the existing code). Any further
> changes can be made after that. I'm open to any patches.
>
Ok, I was suggesting to improve ParseModuleArguments before that, but
I believe I can do it. Of course there's got to be a change in that
example function (above) and maybe others..
I just needed to know if the work is worthwhile or not before doing
the actual work ;)
> > PS: there's a real bug on top of all this text ;)
>
> Hint: Write two mails for two different topics to minimize the
> risk the bad issue is forgotten.
>
Ok, got it.
> Ciao
>
> Dominik ^_^ ^_^
>
Cheers
Renato
