On Wed, Dec 14, 2016 at 9:26 AM Felix Meschberger <fmesc...@adobe.com> wrote:
> Hi Justin > > Thanks for the clarification > > Am 14.12.2016 um 15:14 schrieb Justin Edelson <jus...@justinedelson.com > <mailto:jus...@justinedelson.com>>: > > Hi Felix, > > > > On Wed, Dec 14, 2016 at 8:46 AM Felix Meschberger <fmesc...@adobe.com > <mailto:fmesc...@adobe.com>> > 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. > I'm still not seeing how this is any different than, for example, the Accept header. If a client makes an HTTP request with "Accept: text/plain" and the server can't service the request with a text/plain response, it returns an error. The client is expressing some precondition and the server is responding to it. *How* the server is configured to do this is not the concern of the client, but *that* it is configured to do this absolutely is the client's concern. > > 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 ? Because the client may need to require that certain requests fail when audit is not happening. Again, the nature of that audit is not the client's concern, but it is a concern that it is happening. > > 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. > We shall see... Personally, I'm less confident about our immutable server future :) Regards, Justin > > 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 >
