Hi Justin Thanks for the clarification
Am 14.12.2016 um 15:14 schrieb Justin Edelson <[email protected]<mailto:[email protected]>>: Hi Felix, On Wed, Dec 14, 2016 at 8:46 AM Felix Meschberger <[email protected]<mailto:[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“ Hmm, my concern still holds: This is not a use case but an implementation prescription ;-) 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). Hmm, I think we are starting to tightly couple client to server (am I repeating myself ?). As a client it is *not* my concern that the server is properly setup and configured. What you are proposing, though, is that the client can explicitly request for proper configuration. As such I have the impression we are also violating the separation of concern principle here. 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. Hmm, audit ? Why is this a concern to me as a client ? I cannot audit the server in the least way. Why should I be able to request this for the Sling POST Servlet ? Particularly if there are litteraly 10s and 100s of other POST request handlers in the same system not even supporting auditing ? Granted: I am not against auditing. I am very much in favor of properly doing it. But again, this is a server concern and at best a contractual concern between the client and the server. But it is not an API concern. 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. Going into the future of immutable servers, we can all the more be certain to have that. If functions are important to be had and this is a concern to the server, then server should have a means of defining that the setup is properly done. Maybe we need a validation function to define „the server is properly setup and everything administratively expected is in place“. But this IMHO cannot be a the task of an HTML programmer configuring an HTML form to setup. Regards Felix
