One of the main UI complains with the 0.8.x branch of LibraryFind relates to what happens after the user searches. Since LibraryFind must collocate all the search results together before display, what happens as the user waits (or doesn’t happen) has been an admitted weakness of the program. That will change in 0.9. In 0.9, users will see what’s being queried, number of results, and have the option to kill the search at any time and view the results that have already been found. One additional benefit of this method has been in terms of thread lock. In 0.8.x, a single mongrel instance is locked until a query is completed. This is because the interface never refreshes, but waits for the query to complete. In 0.9, the UI uses micro-queries, hitting the server for short periods of times, allowing mongrels to answer a quick request and then move on. A quick comparison: In 0.8.x, a single query typically takes approximately takes 6-10 seconds to complete (depending on # of targets queried). In the previous model, a single mongrel thread is locked for the entire duration of this query. In 0.9, the average query on the server is 0.005 seconds. While the 0.9 interface makes more queries to the server, these are separate queries, allowing the server to better manage how its pack of mongrels are used and eliminating the thread locking that would take place during queries.
While the UI may change slightly as I finalize the 0.9 interface, here’s a snapshot of what this looks like now:
If you have questions about this, or other LibraryFind development, just give me a holler.
–TR