X-Git-Url: https://git.deb.at/?a=blobdiff_plain;f=TODO;h=d197162c487b24089cb0c4c8b04958d8d871495f;hb=a430a7f2c477de0e9952384e896e7c78cea3f32f;hp=2570d728eacdcf44d2e95eb4c8d9b85e234a316a;hpb=fcdd03b487a852fead30b5f9f6d25f8c36d5c5c2;p=deb%2Fpackages.git

diff --git a/TODO b/TODO
index 2570d72..d197162 100644
--- a/TODO
+++ b/TODO
@@ -4,10 +4,12 @@ search_packages.pl:
     tersely on one line each, with "#foo" links to what's currently displayed.
   - The 'extended' can maybe also have full descriptions then (maybe add did
 	to _small.db?)
+  - Unify exact & subword -- reduce naming confusion with 'exact' meaning
+	either "exactly the same" or "full word"
+  - When doing substring searches, hilight with html backgroup color (css of
+	course) the search term
 - exact package searches
 - substring searches on packages:
-  - don't do exact lookups, but use '^' prefix token
-  - only do for >= 2 characters
   - don't allow whitespace in it, warn when people use common wildcards like
 	*, ?, ^, $ (not possible)
   - When overflow, iterate the first couple of packages that *start* with the
@@ -19,3 +21,39 @@ search_packages.pl:
 - fulltext search:
   - Max 100 results
   - Better exact=1 performance by indexing per word?
+  - drop case-sensitive from options, descriptions.txt all lowercase and without
+	punctuation, such that instead of =~ //, indexof can be used
+  - in results, show full descriptions, so one sees what's being matched?
+
+- backend:
+  - Ensure that in _small.db, newest version for each suite is first,
+	show_package relies on that. So foreach suite, 'newest entry', and only
+	then, all the other entries
+
+Static pages:
+- try to make it faster
+
+General:
+- Try to break everything with empty/short searches
+- Check for case sensitive consistency
+- Fix assumption that archive doesn't show up in any url, consistency-fy
+  dealing with archives of a different set than (us, non-us, security)
+- grep -ri fixme
+- searchon=all -> searchon=descriptions?
+- quicksearch box: copy parameters of current search (exact,suite,arch,etc),
+  or rather, always use defaults? Both have their pro&cons... former is more
+  obscure, but otoh, for typo fixing more appropriate.
+  Maybe best of both worlds is 'modify search' below results, where you can
+  generalize/specificy arch, etc etc?
+- In Search.pm, make sure read_entry_small only scans a bit, and not all --
+  once you have #max_nr_of_suites, you know you won't find the queried suite
+  anymore, so search further is futile. Maybe the backend could even add a
+  marker, ignored by read_entry_all, but understood by read_entry_small, that
+  indicates end of $res2 and start of $res3
+
+
+Missing pieces from old code:
+ - DDTP support (but without a working DDTP I will not invest any time
+   in that)
+ - search_packages compatibility (we should at least ensure we don't break
+   sarge's reportbug)