Hi, turned out that keeping backwards compatibility for ACLs wasn't a big deal, so latest push adds ACLs to public API while keeping backwards compatibility. Last thing remaining before closing the public API is to add the SPI..
br, juan pablo On Sat, Mar 21, 2020 at 8:06 PM Juan Pablo Santos Rodríguez < juanpablo.san...@gmail.com> wrote: > Hi, > > the public API is almost there, as only a couple of things are remaining: > > - an SPI to obtain objects from the o.a.w.api.core package. As this will > be new code, it doesn't present too > much trouble. The main objective of this SPI would be to be able to > provide custom API implementations. The > scope for this will surely be 2.12 > > - Page ACLs: right now WikiPages has getAcl() / setAcl() methods, which > use a couple of objects from the > o.a.w.auth.acl package (Acl and AclEntry). Moving getAcl()/setAcl() to the > o.a.w.api.core means bring in this > two classes. > > I've been looking at a handful of published custom extensions and making > use of Page ACLs does not seem > to be a main priority, so my question is, would it be ok to promote > directly the Acl/AclEntry objects to the > o.a.w.api.core package or would you expect to have some sort of backwards > compatibility? AIUI, pages ACLs > are orthogonal to extensions (plugins, filters page/attachment providers), > so direct promotion would be the > way to go for me. > > thoughts? > > > best regards, > juan pablo >
