IMO it makes sense to deliver *all* the searches and merely have the undesirable ones disabled. This allows the user to enable one of the disabled ones later without having to fetch it from the internet...
Monty > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Brent > Beardsley > Sent: Sunday, September 21, 2003 11:46 PM > To: [EMAIL PROTECTED] > Subject: RE: [DQSD-Devel] Directory Structure Change of Optional > Installer... > > > I think we need to have the ability to enable/disable > in the DQSD app not just the installation program. > > Also I like having the search configuration > information (language, category, enabled status, etc) > in xml so it's explicitly all there and easy to digest > instead of having to interpret things like directory > structure being the category and disabled searches > having a different extension, etc.. > > Just my two cents, > > Brent > > --- "Shawn K. Hall" <[EMAIL PROTECTED]> wrote: > > 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 > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > > ------------------------------------------------------- > 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 > ------------------------------------------------------- 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
