Hi Bertrand,
On Wed, Jan 8, 2014 at 10:53 AM, Bertrand Delacretaz <[email protected] > wrote: > > On Wed, Jan 1, 2014 at 11:27 PM, Dominik Süß <[email protected]> > wrote: > > > ...DevOps optimization: this includes setup, patching, monitoring and > > scalling of installations... > > I also think this is the next big topic to tackle for Sling. I have a > number of (somewhat wild) ideas about this, hoping to get some interns > to work on experiments in that area in 2014. I'm in favor of not going > too far inside Sling with this, and taking a systems approach to > configuration and upgrades management to separate concerns and keep > Sling lean and mean. > I agree that Sling should not force into a specific direction, but it might be that there are repeating patterns where some global/Sling provided (optional) tooling might be a good choice. > > > ...Subtopic Deployments: It is still not clear how to package deployments > > the right way, although various mechanisms are available it seems like > > there still is room for optimization... > > Not sure what you mean by this but the devops work can also help here > - I'm thinking in particular of letting Git or other repositories > drive the configuration of Sling instances, as recently discussed. > I was thinking of application deployments. Sling currently is based on bundles with the initial-content or installing it from the repo from install folders. In Adobe CQ Packages (vlt - contributed to Apache some months ago) are the mechanism to package deployments. So there are multiple ways to organize deployments. Bug e.g. all are tight to a JCR Repository as soon as it comes to content (since there is no generic equivalent to the JCR Installer). what doesn't feel right is that the prefered way of deployment in a Sling based app as Adobe CQ is different from how Sling is doing deployments with the own parts or demo apps (creating a uncessessary learning barrier). > > > ...POST Servlet: this is an area that I have on my list since last year > and > > where I started to work on a proposal for a new version that hopefully > can > > be a base for something that replaces the old POST Servlet and reduces > the > > need for implementing custom Servlets as much as possible... > > I like this, the challenge here IMO is keeping things backwards > compatible, so the starting point is to make sure the current code has > full test coverage. > I'm still playing around with this. keeping everything backwards compatible does create some constraints. I thought about implementing a completely new one (cherrypicking the good parts of the old servlet) and keeping the old one to delegate there where the new one isn't configured. Since one goal is to be able configure where this servlet should act this delegation might be the way to keep backwards compatibility. > > > ...Feature Flags: although the "Feature of Features" seams close to be > ready > > as first draft there is a lot of work left... > > Agreed, at this point we need small reversible steps in this > direction, to help converge on the use cases and how we implement them > as this is very new territory for most of us. The devops systems > approach can also play a role here, as turning a feature on or off can > in some cases be implemented by routing incoming requests to different > Sling instances. > +1 - this is something where reality will bring in a lot of necessary changes I think. > > ...Documentation... > > I already replied to that one in this thread, I'm still a big fan of > readable tests as the ultimate reference documentation, and keeping > written documentation at the overview level to make it sustainable and > accurate. Yet, we have a long way to go here. As a simple thing were > any community member can help, we still have too many old pages under > http://svn.apache.org/repos/asf/sling/site/trunk/content/site/ that > need to be cleaned up as per my comment 04/Apr/13 12:28 in > SLING-2002. > Good inline documentation is really good to understand why things behave as they behave, But you need some guidance when starting with a new technology. I think there is also some room to flatten this initial learning curve by having some documentation/tutorials and/or "guided" demoprojects. > Apart from all that my wish for 2014 is that we can get more people > involved in Sling who are not using CQ, to keep the diversity. Not > only in terms of company influences (I think we're doing ok despite a > majority of Adobe/CQ related community members) but above all in terms > of a diverse set of use cases that help make Sling better by bringing > in different views. > Big +1 on this one. Best regards Dominik
