Provide a way for a POST request to assert a set of required SlingPostProcessors (SLING-6187)

[Felix Meschberger <fm...@adobe.com>]

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.

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 ?

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

Re: Provide a way for a POST request to assert a set of required SlingPostProcessors (SLING-6187)

[Justin Edelson <ju...@justinedelson.com>]

On Wed, Dec 14, 2016 at 9:26 AM Felix Meschberger <fm...@adobe.com>
wrote:

> Hi Justin
>
> Thanks for the clarification
>
> Am 14.12.2016 um 15:14 schrieb Justin Edelson <justin@justinedelson.com
> <ma...@justinedelson.com>>:
>
> Hi Felix,
>
>
>
> On Wed, Dec 14, 2016 at 8:46 AM Felix Meschberger <fmeschbe@adobe.com
> <ma...@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
>

Re: Provide a way for a POST request to assert a set of required SlingPostProcessors (SLING-6187)

[Felix Meschberger <fm...@adobe.com>]

Hi Justin

Thanks for the clarification

Am 14.12.2016 um 15:14 schrieb Justin Edelson <ju...@justinedelson.com>>:

Hi Felix,



On Wed, Dec 14, 2016 at 8:46 AM Felix Meschberger <fm...@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.

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

Re: Provide a way for a POST request to assert a set of required SlingPostProcessors (SLING-6187)

[Justin Edelson <ju...@justinedelson.com>]

Hi Felix,



On Wed, Dec 14, 2016 at 8:46 AM Felix Meschberger <fm...@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"

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