Modularization proposal updated

[Roland Mainz]

Kevin E Martin wrote:
> > > > > I have updated the modularization proposal as discussed.  The changes
> > > > > were to generalize the driver module (as suggested by Keith and myself)
> > > > > and explain that the configure options will be both standardized and
> > > > > documented (as suggested by Egbert et al.).  The updated proposal can be
> > > > > found here:
> > > > >
> > > > >     http://wiki.x.org/wiki/ModularizationProposal
> > > >
> > > > Two things:
> > > > 1. XRX is still no DDX (it mainly belongs into the app/ module AFAIK)
> > >
> > > It's a wiki, you know. ;)
> >
> > Yes, but I am not sure whether anyone else except the author is allowed
> > to edit it (technicially I can edit it but I would prefer if Kevin would
> > do that (since there is no editoral review process for changes in this
> > version of Wiki and I don't like to put random nonsense into other
> > people's work... :))
> 
> I've change it now.

Thanks! :)

> > > > 2. Where should server-specific config files stored (I am mainly
> > > > thinking about the whole XpConfig/ hieracy which the print server needs
> > > > to start (e.g. it will refuse to start without having those files so
> > > > they should be placed close to the server sources IMO)) ?
> > >
> > > Config files belong with the app that needs them.
> >
> > OK... that would be the xserver module then...
> 
> That's a reasonable question.  What should we do with XpConfig,
> xorgconfig, etc?  The app to which these belong is the server.

Same applies to the /etc/init.d/xprint script (at some point it should
be superset with the "xprintadm" utility but that's still some months
away in the future) ...

> > > Does this mean a combined print+display server will fail to start display
> > > graphics if the XpConfig hierarchy is missing?
> >
> > If you force to run it in "print" mode then the answer is definately
> > "yes" (since you will only have print screens in the "print"-only mode
> > and all print drivers will refuse to initalise if the core config data
> > are missing). The same applies to the "video+print" mode but that could
> > be adjusted to a plain warning and then the Xserver only comes up with
> > "video" screens.
> 
> I think this is a good reason why the default is currently to build
> separate video and print servers.

But that will change likely in the future - at some point there should
be a way to make the print modules dynamically loadable and that is only
possible with the "Xorg" server. Replicating the module loader into the
"Xprt" server will only cause bloat there and defeat the idea to keep
"Xprt" around as a small&&standalone print server with only a few print
DDX built-in while the heavy-wheight stuff like the SVG driver should
only made available as loadable module.
HP/UX already did go that path, Sun did a similar work with integrating
Xvfb into the Xsun server (as loadable module and making "Xvfb" just a
wrapper script which calls "Xsun" with the options to load the "vfb"
module and dummy keyboard/mouse drivers) and I think it's the general
way for Xorg, too.

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)