On 10/9/07, David Nuescheler <[EMAIL PROTECTED]> wrote: > ...I think generally I would be cautious about introducing too much > abstraction. > > In many respects unnecessary abstraction causes software to fail in the > market. > I agree with Stefano 100% on this one ...
Ok - I see your point, taking full advantage of JCR instead of trying to hide it might be more helpful. But note that the current OCM is an abstraction on top of JCR, we might want to make its use optional and allow people to use "raw" JCR Nodes in their Sling apps. > ...Some more thoughts on choices and flexibility of Joel on that: > http://www.joelonsoftware.com/items/2006/11/21.html... Totally agreed, I remember reading that one a while ago. And the "paradox of choice" book is also on my bookshelf, a very good read. So at this point, what's left of my ideas about Sling request processing are a) Make the Sling request processing module as small and understandable as possible, clearly separated from the rest (I'll start another "breaking Sling into smaller pieces" thread) b) Make the REST ideas of the Sling request processing module more obvious c) Allow people to use JCR nodes directly if they don't want the OCM stuff -Bertrand
