Hi, > premature optimization
Sure, premature optimization should be avoided. But sometimes you need to validate that a certain architecture / algorithm doesn't result in very slow or unmaintainable code. I mean, that's the reason to write a prototype: so you can actually test it. > clean and easy to understand architecture Yes, make it as easy as possible. For example, I didn't implement a CachingHierarchyManager. I was a bit afraid it will be a problem, but it looks like it's not. That's good. > loose weight You probably mean "speed up". Yes, it's almost always possible to improve performance a bit by tweaking the implementation. But it's usually very hard to "remove code" after it has been added and used. > the prototype currently probably misses tasks that Jackrabbit currently does Sure. But I don't know any that would account for big performance or architectural problems. Shareable nodes was one such case (without shareable nodes the prototype wouldn't need NodeState). > data validation against the node types Nobody uses node types. Just joking. The test case doesn't use node types so I don't think this is the reason why the prototype is so much faster. But there might be other things I forgot. Regards, Thomas
