[VOTE][RESULT] retire oak-mk-remote into attic

[Angela Schreiber <an...@adobe.com>]

The vote passes as follows:

+1 Davide Giannella
+1 Marcel Reutegger
    +1 Michael Dürig
+1 Thomas Mueller
+1 Angela Schreiber

Thanks vor voting. I will proceed as proposed using
https://issues.apache.org/jira/browse/OAK-2693 as
marker issue.

Kind Regards
Angela





On 26/03/15 15:20, "Angela Schreiber" <an...@adobe.com> wrote:

>Dear Oak Team
>
>During initial phase of building a new JCR content repository (OAK),
>we added an remoting layer for the original persistence layer (called
>MicroKernel) which since then has been part of the Oak project.
>
>In the mean time the overall architecture and design has evolved and
>matured and we ended up having all consistency checks, validation and
>security located in the oak-core layer on top of the persistence s.str.
>At the same time we replace the original MicroKernel persistence API
>by the NodeStore API.
>
>Similarly we came up with a whole bunch of low-level inspections and
>repair tools in the oak-run module, while at the same time there was
>little active maintenance/development in the oak-mk-remote module.
>
>Given these developments in our code base, I came to believe that we no
>longer need the MK remoting i.e. the ability to directly interact with
>the persistence layer using HTTP bypassing all validation that assures
>the stability, consistency and security of the repository.
>
>I would therefore like to suggest to retire the oak-mk-remote module
>(e.g. moving it to attic) and removing it of the main oak pom.xml. The
>corresponding JIRA component description should only be adjusted to
>reflect this but will continue to exist.
>
>So, please case your vote for this proposal.
>In case of objection I kindly ask you for some technical description on
>why we need to keep oak-mk-remote in the productive oak project and
>perform regular releases and how we can address the concerns expressed
>above.
>
>Thanks and kind regards
>Angela
>
>
>