Reformatted excerpts from Ben Gamari's message of 2009-10-01: > It seems that C would definitely be a good start (or perhaps C++ would > be a better idea as that is the language in which Xapian is written).
I was proposing that as a strawman argument. C does not solve my problem. > However, I think one of the real issues is the exclusive nature of > index access. In fact, this is one of my primary gripes with the sup > workflow. After processing a large number of messages, the write-out > time can be quite substantial upon killing the buffer. It is possible to address this in a variety of ways, many of which have been discussed over the years, but yes, I agree that a delay is nonideal. > If this were the case, then we could get support for mutable sources > for free, as we could synchronize against sources without interrupting > workflow (although keeping the view in sync with the backend would be > a bit tricky). Making message state saving fast, or backgrounded, is a different beast from scanning over a mailstore. I have been working on a Sup server for quite some time that would address many of these problems, but progress is slow. > As an aside, it would be quite nice if one could run multiple > simultaneous instances of sup. It seems that if one only held write > access to the index during writes (is this the case presently?), there > should be nothing preventing this from being possible. It might be possible to do this with Xapian, especially if there were no expectation of updates being transmitted across processes. With Ferret, if it is possible, it's only with a tremendous amount of effort. -- William <wmorgan-...@masanjin.net> _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
