You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Dominik Süß <do...@gmail.com> on 2014/01/01 23:27:19 UTC
[Happy new year] A new year with Sling (2013 Recap and a whishlist
for 2014)
First of all - Happy new year to all of you from my side :)
The last days I had the chance to think a bit abou what happend in the last
year and what I expect and/or wish for the next year. Since I feel
pretty connected to Apache Sling this also did involve thinking about the
project from my personal point of view. I'm sharing those thoughts since
I do hope to hear your point of view as well and we can push Sling even
further as community.
The year 2013
-------------
At adaptTo() 2013 Mike and Carsten already did summarize the major
technical changes that where adressed until then. By revisiting the
releases of last year it looks to me Sling made a big step forward
improving in various areas like administration/maintenance (e.g.
healthcheck and JMX improvements, Backlog integration), interoperability
(e.g. full CRUD support, Oak Support, Cassandra ResourceResolver, Access
Gates) as well as a lot of little but important updates of the existing
functionality.
Especially in the last two months there is a lot of movement in the
community and a lot of discussions are still open. This kind of
constructive discussion with partially opposing opinions as well as even
concurrent implementationproposals are in my eyes a sign of a vivid
community.
2014 - a whishlist
------------------
This is not a real whishlist but a list of topics that where recently
discussed and some arguments why I personally think it might be worth to
invest some time:
- DevOps optimization: this includes setup, patching, monitoring and
scalling of installations. Ian did start a corresponding thread in November
and I hope this discussion will be pickedup to really fulfill the promise
of a horizontally scallable solution not just on paper but in an
administrable way (addressing secondary items like timing issues for
deployments)
- 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
- 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
- Feature Flags: although the "Feature of Features" seams close to be ready
as first draft there is a lot of work left. One thing not discussed yet is
the usage of featureflags for functionality of Sling itself (tailoring
sling instances to the real needs by deactivating all unused features).
- Multi-Tenant Applications: Although the tenant API does help to implement
multi tenant applications there is still some unleashed potential. E.g. I
am thinking of tenantspecific applicationextentions (might be possible that
featureflags could help here).
- Documentation: This is nothing new and although it recently wasn't topic
on the mailinglist this topic gets more and more important. Everytime I try
to onboard a new dev on Slingbased projects I realize there is more and
more of functionality and it gets harder and harder to teach all relevant
information without having the dev lost in the middle. The golden goal
would be a book covering all the stable parts of sling. IMHO it is
essential for the success of Sling in the next years to flatten the
learningcurve.
This list ist far from complete but those are the topics that I did think
about when thinking about last year. All in all I think the Sling Community
is in a great condition and I can't wait to see more solutions on top of
Apache Sling.
So in the end there is the questions:
What are the topics you think need more/most attention of the community?
Best regards
Dominik
Re: [Happy new year] A new year with Sling (2013 Recap and a
whishlist for 2014)
Posted by Mark Adamcin <ad...@gmail.com>.
On Wed, Jan 1, 2014 at 2:27 PM, Dominik Süß <do...@gmail.com> wrote:
>
> - DevOps optimization: this includes setup, patching, monitoring and
> scalling of installations. Ian did start a corresponding thread in November
> and I hope this discussion will be pickedup to really fulfill the promise
> of a horizontally scallable solution not just on paper but in an
> administrable way (addressing secondary items like timing issues for
> deployments)
> - 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
I'd like to get involved in these issues. I've been doing more and more
work in this area, as it pertains to multi-tier CQ/AEM installations, and
it will likely remain my primary focus for 2014.
Mark Adamcin
Acquity Group
http://adamcin.net/
Re: [Happy new year] A new year with Sling (2013 Recap and a
whishlist for 2014)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Dominik,
On Wed, Jan 8, 2014 at 11:34 AM, Dominik Süß <do...@gmail.com> wrote:
> ...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)...
The OSGi installer can take configs and bundles from the filesystem
already, and implementing a provider that uses a Git repository as its
source might be interesting w.r.t. devops.
>... 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)...
Agreed - historical reasons I guess, not sure how we can improve that.
-Bertrand
Re: [Happy new year] A new year with Sling (2013 Recap and a
whishlist for 2014)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Dominik,
On Wed, Jan 8, 2014 at 11:34 AM, Dominik Süß <do...@gmail.com> wrote:
> ...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....
Yes, and one of the goals of the samples/mail-archive app is to be one
of those tutorials. Still needs work.
What I mean with using readable tests as reference documentation is
that detailed docs tend to go stale. I'd much rather stick to overview
docs that explain the general principles, avoid too many details and
especially copy/pasted code in docs, and point to tests for the
details.
-Bertrand
Re: [Happy new year] A new year with Sling (2013 Recap and a
whishlist for 2014)
Posted by Dominik Süß <do...@gmail.com>.
Hi Bertrand,
On Wed, Jan 8, 2014 at 10:53 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
>
> On Wed, Jan 1, 2014 at 11:27 PM, Dominik Süß <do...@gmail.com>
> 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
Re: [Happy new year] A new year with Sling (2013 Recap and a
whishlist for 2014)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Jan 1, 2014 at 11:27 PM, Dominik Süß <do...@gmail.com> wrote:
> First of all - Happy new year to all of you from my side :)
Thanks, happy 2014 to all Sling community members!
A few comments on your wishlist, in general I agree that those are
nice goals to have.
> ...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.
> ...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.
> ...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.
> ...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.
> ...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.
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.
-Bertrand
Re: [Happy new year] A new year with Sling (2013 Recap and a
whishlist for 2014)
Posted by Robert Munteanu <ro...@apache.org>.
On Mon, 2014-01-06 at 14:08 +0100, Bertrand Delacretaz wrote:
Hi,
>
> On Mon, Jan 6, 2014 at 1:27 PM, Robert Munteanu <ro...@lmn.ro> wrote:
> > ...So, are there any takers on coming up with more structured
> > documentation, something like 'Essential Apache Sling' or 'Apache
> > Sling in Action'? I would be one, but obviously lack the expertise to
> > do this just by myself - and probably the time as well....
>
> I'm interested in contributing. I think we could use the recently
> contributed samples/mail-archive as the supporting app for a more
> complete description of how to write Sling apps. It needs cleanup and
> maybe some restructuring, but IMO it's a good sized example that
> demonstrates many key things.
Sounds good to me. I've created a {skeletal,loosely structured} wiki
page at [1] which we can use for collecting ideas and objectives.
Dominik summarizes the requirements pretty well, but I guess in
addition to that it would be nice if others could add to that.
Robert
Re: [Happy new year] A new year with Sling (2013 Recap and a
whishlist for 2014)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Jan 6, 2014 at 1:27 PM, Robert Munteanu <ro...@lmn.ro> wrote:
> ...So, are there any takers on coming up with more structured
> documentation, something like 'Essential Apache Sling' or 'Apache
> Sling in Action'? I would be one, but obviously lack the expertise to
> do this just by myself - and probably the time as well....
I'm interested in contributing. I think we could use the recently
contributed samples/mail-archive as the supporting app for a more
complete description of how to write Sling apps. It needs cleanup and
maybe some restructuring, but IMO it's a good sized example that
demonstrates many key things.
-Bertrand
Re: [Happy new year] A new year with Sling (2013 Recap and a
whishlist for 2014)
Posted by Robert Munteanu <ro...@lmn.ro>.
(snip...)
>
> 2014 - a whishlist
> ------------------
> - Documentation: This is nothing new and although it recently wasn't topic
> on the mailinglist this topic gets more and more important. Everytime I try
> to onboard a new dev on Slingbased projects I realize there is more and
> more of functionality and it gets harder and harder to teach all relevant
> information without having the dev lost in the middle. The golden goal
> would be a book covering all the stable parts of sling. IMHO it is
> essential for the success of Sling in the next years to flatten the
> learningcurve.
+1 on the need for more structured documentation. If think the one we
have is fine for a very quick dip into Sling, and also as a reference
guide, but falls short when a fresh developer wants to take a guided,
in-depth look at how to work with Sling.
So, are there any takers on coming up with more structured
documentation, something like 'Essential Apache Sling' or 'Apache
Sling in Action'? I would be one, but obviously lack the expertise to
do this just by myself - and probably the time as well.
Robert
--
Sent from my (old) computer