On 20 Jun 2002 at 16:18, Bill Janssen wrote: > Rob and I were discussing the idea of pre-plucked channels for his > desktop tool the other day. The idea is that you put some sections in > your .pluckerrc file which describe "channels". Each channel has some > attributes, such as how often it changes, and the home URL for the > channel. Unfortunately, the only tool which has a parser for the > config file is currently the parser (a bad name; I'm going to start > calling it the 'distiller' again), in PyPlucker/ConfigFiles.py, which > uses the Python built-in ConfigParser to parse the files. So the > desktop has to work through the distiller all the time, which is both > clumsy and error-prone. > > It seems to me that the right thing to do is to write a parser in C > for the config files, so that tools like the desktop can read the > options directly. This seems like a reasonable thing to add to > libunpluck, in fact. What do y'all think?
The desktop does parse the config file okay. There is a wxFileConfig in wxWindows class, that does parsing nicely for ini-style config files, handling the differences in Mac, Linux and MSW text files. A plucker "channel_type" class for things to be passed around was created. It uses longs for bool values so that the channel bool parameters can also carry a "-1" value as it gets passed for "not specified". So for example, if something wanted to add a channel to the config: (1) A channel_type object is contructed and all the parameters are initialized to "-1". (2) The doc_name, home_url, and maxdepth are set for the channel_type object. (3) The channel_type object is sent to plucker_controller::add_channel( channel_type &channel ) This function creates a section in the ini file, and looks through the each parameter of the channel_type object, and if the parameter is not -1, then that parameter is written into the .ini file under the channel's section, for example the output would be: [Slashdot] doc_name=Slashdot home_url=http://palm.slashdot.org maxdepth=3 The potential problem isn't so much with parsing the config file, it is with adding another commandline tool [like wget/curl] which may not work on the system, which is somewhat error- prone. Python in the Plucker install has to be able to go online correctly and retrieve files, or else Plucker is someone dead in the water (unless switch over to a Perl parser or something else). Therefore once Python is working on the OS, the preplucked downloads will also work automatically. wget, curl or something else could certainly be used to download a pre-plucked file and set the downloaded file in the doc_file location. But that means: -Reproducing the download functionality of separate downloading via curl/wget to the detriment of each tool's size, and coding time trying to update them all across all platforms. -Error proneness trying to get the curl/wget to work on each system/platform, avoiding conflicts of other curls/wget versions installed, platform-specific quicks, having proper permissions, setting proxies and other headaches. My thoughts on Plucker distiller functionality is that it be allowed to be passed a section in the ini file as part of its public interface, and as its public output, it makes an output file appear as the doc_file. If there is a precompiled=1 parameter in the section, the distiller just downloads the home_url verbatim and just copies it to whatever the doc_file parameter is. Other Plucker toolchain members both past, existing and future can thus treat the input and get output from the distiller the same for precompiled channels as for channels that need to be rebuilt from the HTML. Best wishes, Robert
