From: Terrel S. <tsh...@tr...> - 2001-04-09 23:40:35
|
<sigh>. Another long post from Terrel. I will spare you the bandwidth until you are ready to read it. Keywords: BuildKit, CacheKit, PatchKit, horizontal scalability, easy deployment, reliable updates. Abstract: Most web content is fairly static -- i.e. the read:write ratio of individual source components is very high. Even so called "dynamic" content usually involves relatively minor customization of a template based on session data or a slowly changing variable. A dependency management framework can reduce the complexity of merging the static and dynamic components and increase consistency of updates to content. Integrating a caching framework allows cached targets to be shared among several load-balanced servers. Text: http://www.ics.uci.edu/~tshumway/webware/dependencies.WEP.html -- Terrel |
From: Chuck E. <ec...@mi...> - 2001-04-10 03:27:02
|
At 11:41 PM 4/9/2001 -0700, Terrel Shumway wrote: ><sigh>. Another long post from Terrel. I will spare you the bandwidth >until you are ready to read it. > >Keywords: BuildKit, CacheKit, PatchKit, horizontal scalability, easy >deployment, reliable updates. 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. 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. This is intense stuff along the lines of a dissertation. Maybe you could obtain the first Webware-related Ph.D. :-) -Chuck |
From: Terrel S. <tsh...@tr...> - 2001-04-10 05:22:23
|
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. -- Terrel |