Hi John, > OK Guys here I go with big architecture type change > suggestions. Can we begin to break the Search directory > up into subdirectories? I mean under search there would > be a directory for each search category. > So the structure would become > .\searches\Computers\Networking > .\searches\Computers\Programming > And so on. > Then the relevant searches would go in the right directory.
This would make it possible to have two searches with the same name. Granted, that's possible now, but only the last has bany effect. At least within the same folder they're easily determined to be single. That's the only detrimental (and even that is questionable) side-effect I see. > The reason is for the optional installer. Currently EVERY > search HAS to be individually listed in the installer. Why? Wouldn't it be better to build an index file that could be readily reparsed/rebuilt at each reload? In this way, it would be able to be immediately extensible as well. A new search is dropped into the searches directory, you reload it (!) - which triggers a rebuild of the index since one or more file dates are after a certain cached value (updated files changed after the last explicit disable should be re-enabled). Categorical selection would still be possible, but based on the xml index file instead of building and storing the information in variables - that way only the 'live' values are kept in memory. A "help/?" query could also return an XSL transformed presentation of the XML file directly, instead of manually building the results each time. The settings for enabled/disabled searches and selectively modified categories could all be stored as <preference> tags in the index, too, which would keep all the user-level changes to the searches themselves within the same file. The benefit to this being that it could be set to be ignored from CVS so people's own 'custom' mass search disabling schemes wouldn't be as hard for the contributors to deal with. For example, I used to have all the searches I had 'disabled' renamed from *.xml to *.disabled - but when I got CVS access that was no longer feasible (even though more than half of my searches were disabled). Now DQSD (since the files are again *.xml) wastes memory space keeping cached information about searches I will *never* use. It'd also be nice to be able to disable add-ons in the same fashion (preferably in the same index file). > ....the installer would not need to be edited just because > a new search was created. I think all the searches should be "installed" (copied to the system) - seriously, we're talking about 700kb of installed text files - compressed it's less than 300kb. Install all of them but have the installer provide a simple interface to disable, en mass, categories so the user doesn't have to have them taking up ram. Regards, Shawn K. Hall http://ReliableAnswers.com/ '// ======================================================== "I wonder if he's using the same wind we are using?" -- 'Inigo', The Princess Bride ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ DQSD-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dqsd-devel
