Hi guys, > > For me sling has a very simple main purpose: > > It is the JCR centric web application development > > framework of my dreams. > Yes, true, but ... "JCR-centric" is a very vague term in itself :-) I agree that there are many flavours of how you could use the a content repository, there should be a recommend way though.
In my mind the initial message should be: If you would like to build a webapp using a content repository ...use sling. I think sling will be more successful providing "rails" instead of "options", in a sense something like: If you want to build a webapp using a content repository, this is how you develop, deploy and run it. (sling: osgi, rest, content packages, ...) > > I think being more osgi than web framework A or > > more restful than framework B does not really justify > > slings existence. I think it is crucial for the success > > of sling to be able to argue why it is different, > > not so much why it is incrementally better. > I do not completely agree here: There are multiple requirements for a > web application framework: Extensibility, Manageability, Stability, > Ease-of-Use, Data Persistence come to mind; certainly there are more. I completely agree, but don't ever want to find myself in a in position arguing why sling easier to use than wicket or more extensible than spring. If someone ask me: "why should I use Sling?" then my answer will always be "...because you believe that everything is content." > Now, Sling is probably not revolutionary with respect to a single > requirement (except with regard to Data Persistencew) in that it is > better to extend than framework X, better to manage than framework Y > etc. All-in-all, when counting all parts together, you get a framework > which is dramatically "better" than other frameworks in the field. And > this is IMHO the real value of Sling. I think I am in no position to judge the extensibility, stability or manageability of other webframeworks, simply because I have not used any of them long enough. ;) However since perception is reality, I think we will never be able to be (perceived as) more robust and extensible than spring or easier to use than wicket or ror. So in my mind attempting to differentiate along these lines is pointless... Let me try to explain my view differently, the most trafficked "Photo Managment Application" on the net is facebooks. It lacks tons of features (until recently you were not even able to sort photos), but it has its "secret sauce" which is the "Social Graph". In my mind slings secret sauce is the Content Repository. > > I think putting the Content Repository at its core > > certainly gives sling a very clear and easy to > > express differentiator. > This is what we do, except that we do not lock the Sling API into the > JCR but say, a Sling application may depend on Sling providing the data > to work with in a uniform fassion and that Sling applications do not > have to care much about persistence issues. This is IMHO a big > differentiator to most if not all frameworks around. I think it is very common for web frameworks to abstract their persistence. Amongst the ones that I can remember off the top of my head only very few don't. > Currently, Sling is of course locked into JCR, as the Content > provisioning only supports JCR and authentication depends on and > requires the JCR repository. I agree and it sounds like nobody has a real-life usecase to use something else really. It reminds me a bit of the argument "Yes, SOAP could be sent using various transport protocols, but in reality people only use http, and there really is no reason not to use http ;)" ...so why the abstraction? I think abstraction or indirection always come at a price. regards, david
