Comment 7 for bug 643544

I've checked out Christian's changes so far, but have some feedback (also given verbally to Christian):

* More input validation is still needed, as search strings like "1::7-5-1-6" don't produce errors (but also no results). With a little imagination, many seemingly crazy search strings seem to be parsed as valid.
* An explicit message to end-user when a search has yielded no results. ATM, it looks like nothing happened when there are no search results, it looks like one never left the search form.
* An explicit statement of what the end-points of the search string were interepreted to be. When inputting "10.0.62.183/" as a search string, it's nice to know that the results are within the range "10.0.62.0-10.0.63.255".

One thing we didn't discuss in detail is how to support searching for host names instead of IP addresses. Vidar suggests picking an IPv6 address if available, but I'm wary of this. A hostname could potentially resolve to a multitude of IP addresses, both IPv4 and IPv6, and I think its crazy to randomly pick one of these when it is not clear what the user's intention is. I have two suggestions:

either:
* If a hostname resolved to multiple addresses, no default selection should take place, rather Machine Tracker should explicity state that there were multiple matches for the given hostname, and list all the matches as clickable links to new, explicit, Machine Tracker searches.

or:

* Machine Tracker, which today is geared towards simple range searches, should gain the ability to search for disjoint ranges, e.g. one could possibly input a list of IP addresses and matches on any of these will be shown. A hostname resolving to multiple addresses would search for all those addresses (but would be even more complicated if hostname is used in conjunction with a netmask). This would likely be more work.