From: Robert L K. <rl...@al...> - 2003-10-25 12:51:16
|
From: Roger Leigh <ro...@wh...> Date: Wed, 22 Oct 2003 23:47:40 +0100 On Tue, Oct 21, 2003 at 07:55:11AM -0400, Robert L Krawitz wrote: > From: Roger Leigh <ro...@wh...> > Date: Mon, 20 Oct 2003 23:19:49 +0100 > > Another approach might be to put different files (printers, papers, > dither matrices etc.) into subdirectories, which could then be processed > separately at different times, or specifying files /not/ to autoload. > > The first seems better. Specifying files *not* to autoload doesn't > solve what I believe to be the real problem. OK. How about subdividing the XML data dir into: dither-matrix/ papers/ [family/$familyname:] family/epson family/canon family/pcl etc. The family driver data won't need to be loaded until after the corresponding family driver module is opened. The dither data won't need to be touched until we need to get a dither matrix, etc. We could even defer loading the papersizes until the first papersize lookup. This could even mean deferring /all/ XML data loading until specifically requested, and then parsing a whole subdirectory. If we still read the top-level directory, files in there would still get "preloaded" if required. That's certainly a possibility. I'm really uncomfortable with things being loaded automatically in nondeterministic order (and for that matter I consider simple alphabetical sorting to be "nondeterministic", since it doesn't really have any semantic meaning). It's simply too hard to test. I'd rather that an individual module requests files to be loaded in a particular order. It can still do the path search thing to find all files in a directory, and then load them in whatever order it pleases. It's just that saying "we'll load any file the user drops in here" is asking for trouble. > Please could you explain how there will be inter-dependencies between > the XML files? Would it be better to put any dependency information > into the XML files themselves? > > Suppose there's a top level Epson HTML file that contains information > about printers. For example, it contains the head parameters for each > printer. A logical way for the Epson driver to store this data would > be to attach it to each defined printer. Now, suppose the Epson data > is loaded before the global printer data? How about having [epson-inks.xml] <gimp-print> <depends file="epson-base.xml"/> <stuff> </stuff> </gimp-print> If we check for a <depends> tag straight after loading a file, and the check fails, we can defer processing it until the constraint is satisfied. If it's not satisfied by the end of a run, the file gets dropped. This just sounds unnecessarily complicated to me, that's all. If there's a nice straightforward primitive "load this file", and a path search capability, modules can build on top of that as needed. -- Robert Krawitz <rl...@al...> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |