Reformatted excerpts from Rich Lane's message of 2009-07-31: > I tried out using add_term/remove_term for immediate label changes. > It's significantly faster than sync_message,
Excellent. > but it still makes the interface feel laggy. There's known room for > improvement in Xapian's replace_document. However, we'll still have a > lot of latency when we start using remote sup-servers, so I don't > think it's a good idea to do these index operations synchronously with > the UI. I agree, synchronous is not an option. > We could queue up index writes and execute them in a background > thread. We'd want label additions to show up immediately in a search, > though. This is easy to do for inbox-mode and label-view-mode, which > covers most of my daily usage. I'm fine with queuing up index writes and letting the user continue while they take effect in the background. I'm also fine with the easier option of just blocking during a search until the writes are complete. > If/when we support multiple clients connecting to a sup-server, we'll > need a way to notify them that someone else modified a message. I think this is more of a nice-to-have than a necessity, but it would be nice to have, even if it was a "we've detected a change somewhere on the internet; reload? (y/n)"-kinda thing. > How is sup-server development going? Well. I have a simple version that stores "items" to files on disk, and uses Ferret to provide the search semantics. It's modular enough that upgrading to Xapian shouldn't be as painful as it was with Sup. There are even unit tests that enforce the semantics of the modules. Go me. I'm going to make a couple internal API changes in Sup and then try throwing the code together. -- William <[email protected]> _______________________________________________ sup-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/sup-talk
