Chuck Esterbrook wrote:
> This is very different from what I had in mind for "CacheKit", which is
> more like what SessionDynamicStore does and what UserKit intends to do.
> That would be stuff like pushing inactive objects out to disk and killing
> really inactive objects.
> But that doesn't invalidate your ideas at all. I think BuildKit et al look
> very interesting. I just think we're in two different semantic spaces.
Perhaps they are targeted for solving different problems, but conceptually, I don't think they are that far apart. I know that BuildKit will certainly benefit from the type of caching done by SessionDynamicStore. My idea for CacheKit (not really my idea), perhaps is a little more general, and can persist things much longer than one would typically call a "cache", but the same idea prevails: keep something close at hand that you think you might need. You would not cry about it disappearing because you could always get it again via some longer path.
Hmm. four major storeage classes: memory, disc, archive, source. SessionDynamicStore handles 1<=>2. BuildKit also needs 2<=>3, 1<=4, and 2<=4 (3<=>4 doesn't make sense)
> Getting back to BuildKit, maybe this should all go into one Kit, possibly
> called "GraphKit". At least that's what I'm reminded of: at the center is
> an explicit graph of objects and dependencies which can then be used for
> building and caching.
I can put the cache package into BuildKit, or call it "LongTermCacheKit" (just kidding). I do not plan to support general graph algorithms, only the few necessary to support dependency tracking.
> This is intense stuff along the lines of a dissertation.
> Maybe you could obtain the first Webware-related Ph.D.
Whoa! DFS trees and topological sorts are not THAT intense. make has been doing it for 30+ years. 8-)
BuildKit may delve a little deeper because it has to do everything on-line, but not too much deeper.