Hi Frank, (skipping your many remarks where all I have to say is "OK"...)
> qa.openoffice.org has a Java-based API test framework (OOoRunner, if > that's still the current name), if you want to go this way. Yes, I had seen that. Isn't this framework supposed to be written by different people as the developers? (QA people) > So, there is not really a need for a driver to do caching. My problem is that the driver relies on an existing API (kabc = KDE address book connectivity). If I understand that API well, the only way to proceed is to load the whole address book in memory, iterate through it, perharps add or remove records, and save the result if modified. Therefore the "caching" is imposed to me by the API. Perharps the management of the concurrency is done in KDE's code itself, and all I have to take care about is not to keep lists of addressees alive too long (1). Or perharps I need close and reopen the address book at every query. Perharps even my existing code is already safe against concurrency. I don't know, I have to discuss that with Tobias, who maintains that code at KDE. That's a technical problems that we can discuss off-list, I guess. In any case, I would need to test first whether the problem is real or merely imaginary ;-). (1) Currently, they have a life term equal to the duration of a PreparedStatement or of a Statement object. Which is rather short, if I understood it well. > Then, concurrency wouldn't be a great problem anymore: Simply query the > KAB every time your cursor is moved to another record. That's precisely the problem: you can't query an isolated record (2), you load the whole address book at once. Please remind it is considered to be "small amount of data", unlike usual databases. (2) unless I missed some point, of course. Best, --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
