o Maybe Dominik has another solution, but my "best" solution is
o something like this. Send all bits packed by hand (not C structure),
o and send the scheme using the described MX_WINDOW_FLAG event.
Yeah, we're on the same page, for what my novice opinion is worth. The
only thing I would think wasteful is if we actually broke each flag out
into, say, a char value so it got across the network okay. In terms of
re-packing, you're going down the same path I was thinking, so here's what
I hit: how do you account for endianness? I guess we assert that the
messages are in network-byte-order, but that means that we will have to be
very careful about making sure that every platform gets its endianness
right when the data leaves.
With this in mind, MX_WINDOW_FLAG seems even more attractive (as opposed
to a generated perl file, since it will solve the problem for every
module, no matter the language).
Do we send it automatically, is there a request, or is it part of
config_info (that last one doesn't seem right)?
-- Sal
smile.
o
o Advantages as compared to your solution:
o
o * sent data is not compiler specific
o * more network-optimal, currently window_flags contains some internal
o window state useful to fvwm only, it would not be sent
o
o Disadvantages:
o
o * less performance-optimal, requires a work to pack flags
o * probably more difficult to maintain, but this is not clear yet
o * replacing the sent window_flags is a risky change
o
o Both solutions are similar in that they require the same MX_WINDOW_FLAG
o to define the scheme. Also, the Perl code written for one should not be
o changed when switching to another.
o
o So, I think, we may start with adding a new event and not changing any
o existing events. Then later we may raise the question again of whether
o the compiler specific format is good or not.
o
o Regards,
o Mikhael.
o
o
--------------
Salvatore Domenick Desiano
Research Scientist
NASA Ames Research Center (QSS Group, Inc.)
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
