On Mon, 2003-09-22 at 18:25, Jody Goldberg wrote: > On Mon, Sep 22, 2003 at 02:33:05PM -0700, Bob Smith wrote: > > > > This is one of the things we have been discussing. Doing a single file > > plugin which would be slower, but caching the data so that only the > > first time the plugin is probed its slow. So, say, I add the foo.py > > plugin. The next time I run Gnumeric, the startup time is slow since it > > has to probe the new file and extract the metadata. This meta data is > > added to the plugins.cache (or whatever) file and then subsequent runs > > of gnumeric just read in the plugins.cache file since there are no new > > plugins. This makes adding new plugins easy and makes startup times > > quick other then the first time. > > Ahh, I see what you mean. However, the 'magic just in time caching' > of plugin data scares the bejeezus out of me on several levels. > > 1) Its a source of consistency problems, and permissioning issues I considered this. My initial thought is to put the cache somewhere like ~/.go/plugins.cache. This should eliminate permissioning problems. As to consistency, that mostly falls into your number 2. > 2) We still end up having to do the scan initially to see if > anything has changed, so the net win is small. checking existence/last modified would be about the same performance as searching for the xml files like the system currently does. It probably will be a bit faster too since you don't have to worry about parsing xml. Do you have any other concerns? The stuff you've mentioned does make it harder to implement, but I'm willing to do the work unless you can convince me that its too much work. :) > > If we're going to do it I'd rather see a package/plugin installation > level operation that would update the list of available plugins in a > subtree. If you can convince me that the caching idea is too difficult this would defiantly be my next choice. --- Bob Smith <bob thestuff net> --- ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++ ..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
Attachment:
signature.asc
Description: This is a digitally signed message part