On Wed, Jul 30, 2003 at 06:52:55PM +0200, Emile van Bergen wrote: > Hi, > > On Wed, Jul 30, 2003 at 06:21:37PM +0200, Giuseppe Sacco wrote: > > > Il mer, 2003-07-30 alle 17:47, Emile van Bergen ha scritto: > > ... > > > These are still sufficiently abstract for use on character terminals as > > > well as frame buffers, but allow you to build higher level widgets > > > (partition selectors) independently from the rendering backend. > > > > This is the point: I think that different rendering backend may be VERY > > different and act VERY different. Otherwise you are back at the almost > > ask/answer machine (cdebconf), > > > > If you give low level functions available to d-i submodules than the > > complete UI should be managed in the (let's say) "partition" submodule, > > while the point is to let the partition submodule abstract from the UI > > and act like this > > > > if (load(guimodule)) > > guimodule.doall(mycallbacks) > > else > > cdebconf fallback > > > > I like this idea but I am very new to the installer, so take it as a > > hint. > > I really hate this idea, as it creates a programmatic interface (the > 'mycallbacks') that must be known both in the partition module and the > guimodule. Both do parts of the work, and are only useful in one > context. They must be kept exactly in sync. > > All callbacks are ugly in general [0], because A (the caller) needs very > specific knowledge (at the individual function level) about B, and B > also needs such knowledge about A. > > A and B quickly become so intertwined that arguably the modularization > is useless, because whenever A evolves, you'll have to update B as well. > Putting callbacks in an interface that's still evolving will create > spaghetti in no time. > > Whether you put a narrow interface at a very high level (installer > steps) or at a low level (individual widgets) can be debated, but > putting it in the middle with callbacks all over the place should be out > of the question. > > It'll become much more of a maintenance nightmare than boot-floppies. > I like the wire protocol idea. A pipe will do fine for this purpose. I have to admit that I'm a server/client fan. installer-debconf will be the server and the various frontends are the clientsss. IIRC there is already a wire protocol in debconf and it uses standard input/output for communication. Create on server side two named pipes serverin and serverout Perhaps a thrid one named servererr On client side will the pipe serverin be opened for output and the pipe serverout, yes indeed, for input. It would be nice the data over wire is human readable. My favorite start-of-text character is <carriage-return> and <linefeed> as end-of-text character. > > Cheers, > > Emile. > > [0] All generalizations are false, including this one -- Mark Twain. > Geert Stappers
Attachment:
pgplixgtkKtEB.pgp
Description: PGP signature