Finally getting back to this after the holiday weekend here in the US. First, David, thanks for taking the time to respond. It's always helpful to have the original developer's perspective.
I'm going to go ahead and chop out most of the helpful email you wrote so I can respond to what I think are the key points. > In my view, the above design was a good design. I havent followed > enough of the details of the 2.0 restructuring to say at the class > level if it would still be right, but I suspect it would. With one big > issue: the one Craig raises below about how security and caching play > together. Yes, this is an absolutely enormous issue. In fact it's the key to my resistance to going back to what we had. > Imagine some WikiTalk that displays a list of all topics in > the current namespace but Sue and Tom both have different permissions > for the various topics. If Sue can see topics A, B and C and Tim can > see A, B and D, the caching becomes tricky. I dont know the right > solution, but something that jumps out at me right away is that the > cache keys could be extended to encode the dependency on the > permissions checks that were passed (e.g., dependent data like a user > name). In this example, that would mean that instead of a cache key > like TOPICS-IN-NAMESPACE-X, you would end up with TOPICS-IN-NAMESPACE- > X(Sue) and TOPICS-IN-NAMESPACE-X(Tom). Not all cache entries would > depend on the specific user (or maybe they would, not sure). > > Its a start of a thought, anyway. > > My overall point would be that I think the caching architecture was > actually pretty loosely coupled and as long as the right events could > be generated from the federation again (I assume they arent anymore) > that a lot of the old code could be made operational again if we > could solve the basic architecture question of how the caching and > security interact. I think it's going to be pretty difficult to take the approach you outline in the general case. I can think of several issues, but here's one off the top of my head: we permit role-based security checks. So it's possible that Tom and Sue are both allowed to read a topic, but only because they're both members of group WikiEditors. Or that Tom can read because he's a WikiEditor but Sue can't because even though she's in WikiEditors she's also in WikiEnemies. Information about role membership is completely external to FlexWiki - if you're using Windows auth, for example, it's kept in a Windows domain controller somewhere. The only reasonable invalidation strategy in that case is to blow up the whole cache if anyone changes any role-based permissions anywhere (the same is probably true for user-based permissions, too). However, putting any knowledge about the fact that role-based permissions are 'special' for the cache just couples the two things again, which is what I'm trying to avoid. So far, the decoupled content pipeline architecture has proven *very* useful - I've already been able to add a few features in a really clean way. So I think it's worthwhile trying to stick with it. Here's another issue: the relationship between different types of permissions. That is, allowing Edit implies allowing Read, and denying Read implies denying Edit. Right now, that relationship is encoded entirely in the AuthorizationProvider. As soon as those rules leak out into a caching infrastructure, or as soon as the AuthorizationProvider has to know about adding cache invalidation rules based on permission changes, then the two subsystems are coupled again. That said, it's entirely possible that that's just how it has to be. It wouldn't be the first time that performance concerns have dictated unsavory design choices. Indeed, there's the old axiom that "all problems in software design can be solved by adding a layer of abstraction" and the relevant corollary "all problems in performance engineering can be solved by removing a layer of abstraction". It's just that my experience with the codebase, with performance engineering, with design, and with maintainability issues make me think that we *really* want to look hard before we walk away from a well-factored design, which is where I think we're at now. Indeed, if it were fast enough, I don't think anyone would argue that we're not in a good place. I think the thing to do is to keep hammering at the performance for now without changing the code too drastically. I for one am not convinced that I don't have some sort of horribly stupid bug somewhere causing tons of I/O instead of serving out of cache. It doesn't seem exactly right to me that some of those pages should take 30 seconds to render when all the data is in cache: computers can do a *lot* of stuff against memory in 30 seconds. Along those lines, I have an idea I need to work on for a while. I want to write a test harness to drive some of these same pages we're having trouble with, but outside of the web app. Profiling web applications is a PITA, and I think if I can do it in a console app instead then maybe I can get a bit better visibility into what's going on. Maybe it's the case that what's going on is that pages with WikiTalk are inherently slow for really good reasons, and the only way to speed them up is to go back to David's original approach. But I'm not convinced yet. If nothing else, I want to know why the optimizations I checked in last week didn't make a *much* bigger difference than they did. Seems like they ought to have. My two cents. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
