JAMES-2884 Rename classes to more closely match the JMAP spec

[cketti]

This pull request renames the following classes:

• ProtocolRequest to InvocationRequest (it models the Invocation type from the specification)
• AuthenticatedProtocolRequest to AuthenticatedRequest
• ProtocolResponse to InvocationResponse (it models the Invocation type from the specification)
• ClientId to MethodCallId (the spec simply uses the type String for this; but the element is called "method call id")

This change should make it easier to map classes used in James to types from the specification. Another thing that motivated this change is that ProtocolRequest would be a good name to use for a class that holds the properties of a (current spec) request, namely, the using and methodCalls properties.

{
  "using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
  "methodCalls": [
    [ "method1", {
      "arg1": "arg1data",
      "arg2": "arg2data"
    }, "c1" ],
    [ "method2", {
      "arg1": "arg1data"
    }, "c2" ],
    [ "method3", {}, "c3" ]
  ]
}

This pull request only renames classes, fields, methods, parameters and local variables. None of the functionality has been changed.

https://issues.apache.org/jira/browse/JAMES-2884

[cketti]

Another thing that motivated this change is that ProtocolRequest would be a good name to use for a class that holds the properties of a (current spec) request, namely, the using and methodCalls properties.

And it could look like this:
cketti/james-project@JAMES-2884_rename_classes...cketti:JAMES-2884_protocol_request

[chibenwa]

Many thanks for this nice pull request!

Yes, terms had evolved within the JMAP specification, and a bit of update here is more than welcome!

[cketti]

Regarding https://www.mail-archive.com/server-dev@james.apache.org/msg62072.html:

After creating the PR I realized there's a chance you might want to keep the draft JMAP implementation around for a bit. The proposal on the mailing list sounds reasonable to me. But I think in that case the classes shouldn't be renamed like proposed in this pull request. What do you think?

[chibenwa]

In my opinion, as preliminary steps, we can get the code organization (of the old spec) as close as possible to the new spec.

It does not hurt.

The red-line is changing code within server/protocols/jmap-integration-testing (where we exercise all of the tested input/output of the old spec), and that you did not do in this PR.

So it's a step in the good direction, and that does not affect existing deployments. As such it makes the work described on the mailing list easier as well, and thus I belive we can still merge it.

[mbaechler]

Thank you for this PR, that's a very good move.

[chibenwa]

Hi,

This pull request has just been merged.

I don't have write access to this repository, hence I can not close this issue. Wouldn't you mind doing it for me? It would avoid me annoying the Apache INFRA team with such simple concerns.

Cheers,

Benoit

[Arsnael]

Thanks a lot for the contribution, nice work :)