Menu
▾
▴
#34 search xml file versioning
Would be nice if there were a version element in each
search xml file that would be updated when the script is
updated so we could tell if we have the latest version.
Would also be nice to have a way to find out what newer
versions of scripts are available and selectively update
all or some of them independently of re-installing a new
version of the whole application.
Logged In: YES
user_id=130313
What is perceived to be the advantage of this? I worry that
trying to maintain ~150 different version numbers will be
difficult.
If the idea is to get away from hassle with doing upgrades of
the main code, perhaps we should address this. I'm not
convinced that a search-only upgrade would be reliable, as
new searches often uncover problems with the code which
require matching upgrades.
Could you expand on what you see as the advantages?
Logged In: YES
user_id=18127
Will,
I can see advantages to this. I think it needs to be expanded,
though. Here's what I would propose be added to the search
schema:
- an optional <version> tag for each search
- an optional <minimum_dqsd_version> tag for each search
Advantages:
- nothing about the current searches needs to change
- the potential to check for and download updated searches in
a central repository (SF CVS?), without waiting for the next
release to be packaged
- the <minimum_dqsd_version> can prevent loading of
searches that require some newer feature in the core code.
IMO, the biggest hurdle (and the most work) right now is a
central repository. The current version in CVS might not be
the best place to pull files from, and I don't relish trying to do
HTML scrapes to get information about the searches in CVS.
(Ideally, the CVS web service would have some type of API
that we could use.)
Maybe it's best to 'publish' searches as they are finalized to
Dave's host machine (dqsd.com), and serve them up from
there. It would be fairly straightforward to do that, if we could
host some PHP server code on Dave's machine. (I did a
quick check a while ago to see if PHP was installed on
Dave's host machine, and it did not appear to be.)
Logged In: YES
user_id=219805
Originator: NO
We should also add country-related values to the searches. While they wouldn't be useful on their own, when we DO have a GUI to manage stuff like this, it would be very easy to, say, disable all the "UK" searches (since they don't apply to me) or quickly enable all of the US and Canadian searches if I live near the US/Canadian border. We might consider adding a value for language support required (iow, UTF-8, Korean, whatever) as well. That'll make it easier to disable language-related searches that are of no interest to me. This all ought to be discussed in the dev group, though.