Hi Felix,
On Wed, Dec 14, 2016 at 8:46 AM Felix Meschberger <[email protected]> wrote: > Hi all > > Can we have the discussion on the list instead of the issue ? This makes > it a tad easier to follow and discuss. > > My concern was: > > > Justin Edelson I share Alexander Klimetschek's concerns (and sorry for > being late to the party as well). Somehow this really smells very badly. > It's like exposing some implementation and machine details. It ties clients > into explicit implementations. Basically I allows for close coupling of > clients with post processor implementations. It think this is wrong. > > Maybe I don't understand the use case fully (I just read the proposed > implementation). What problem does this solution try to solve ? > > Justin replied: > > > Felix Meschberger the use case is laid out in the issue description – a > POST request may depend upon the presence of one or more post processors. > > Actually, the issue description essentially justs says: I want to > implement a new parameter to list required plugins. This describes the > solution not the problem. > Sorry, I meant the issue *summary* (not description)... "Provide a way for a POST request to assert a set of required SlingPostProcessors" Put in more generic terms, a client should be able to assert some set of preconditions that the server must be able to meet before handling the request. I was initially only concerned about expressing this precondition in terms of the availability of a set of SlingPostProcessors, but I can see the value in expressing this in a more generic term (capabilities, features, whatever). > Alex brings up the use case of encryption: > > > What if the sling post servlet understands the @suffix (in this case > @Encrypted) and detects if no post processor has handled it? > > That sounds like a good use case. And also I like the solution much > better. Because it is inline with what already do for typing values with > @TypeHint, and other features. > > Justin contends: > > > I'm trying to solve this problem in a generic way that can be reused > across multiple PostProcessors > > I ask: YAGNI ? > Audit is the other case that comes to mind. It is not uncommon in my experience to use SlingPostProcessors to store audit history. In this case, there is no @suffix used -- the SlingPostProcessor simply does some additional record keeping (potentially in an external system). In these cases, you may need to block POST requests requiring audit if the AuditPostProcessor wasn't available. This works currently because we assume that the server is correctly configured at all times. But that is not always the case and, in both the encryption and audit cases, there needs to be some way of failing requests if the preconditions aren't met. Regards, Justin > > So, if the problem really is that we want to ensure encryption is handled, > we could indeed do that with the @Encrypt notation and thrown an error if > the @Encrypt is not known. > > Regards > Felix
