You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Tellier Benoit <bt...@apache.org> on 2019/12/02 07:33:06 UTC
Webadmin modularity: action registration
Hi all,
## Context
While contributing a way to rebuild JMAP fast messageView projection via
webadmin, we end up with the need of supporting the following actions on
the same endpoint:
Example:
POST /users/BOB/mailboxes?task=rebuildMessageFastViewProjection
POST /users/BOB/mailboxes?task=reIndex
ReIndexing is a task defined in mailbox-api that any backend relying on
a message search index can rely on.
rebuildMessageFastViewProjection is an action that only make sense for
products shipping JMAP.
We need a way to 'combine' both actions within one endpoint in a modular
way.
## Proposal
- Defining a `TaskRegistration` object:
```
class TaskRegistration {
private final TaskType taskType;
private final TaskGenerator taskGenerator;
}
interface TaskGenerator {
Task generate(Request request);
}
```
- Thus a @Named task factory can collect task registration for each one
of these 03 endpoints, which can thus be defined in a modular way.
- We can thus post ReIndexing to be using these taskDeclaration
- And finally using them to add task=rebuildMessageFastViewProjection
support to this endpoint.
## Consequence
Each back-end can register the actions that make sense for it.
We would furthermore ship a mechanism allowing a REST resource oriented
mechanism that will prevent in the future the creation of RPC like
endpoints.
Would such a proposal make sense?
Best regards,
Benoit.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Webadmin modularity: action registration
Posted by Matthieu Baechler <ma...@apache.org>.
On Mon, 2019-12-02 at 17:24 +0700, Tellier Benoit wrote:
[...]
>
> > Are routes modular or each endpoint can declare some point of
> > extensions?
>
> Each endpoint will have to declare it's own extensions.
That sounds like a good choice
>
> Note that my proposal leverage the Task model we use on `POST`
> actions.
>
> > Cheers,
> >
>
> Taking `POST /users/BOB/mailboxes` endpoint
>
> UserMailboxes routes takes a Set<TaskRegistration> as a constructor
> parameter annotated with @Named("allMailboxesTasks")
>
> We write a task registration for user mailbox reIndexing (action
> reIndex) generating the task to reIndex one mailbox.
>
> We for user mailbox jmapView recomputation (action
> recomputeJMAPFastMessageViewProjection) generating the task to
> recompute
> JMAP fastMessageView projection.
>
> Binding to TaskRegistration action reIndex can be done in
> webadmin-guice-data.
>
> Binding for TaskRegistration action
> recomputeJMAPFastMessageViewProjection can be done in
> webadmin-guice-data-jmap.
>
> I can then be calling:
>
> - `POST /users/BOB/mailboxes?task=reIndex`
> - `POST
> /users/BOB/mailboxes?task=recomputeJMAPFastMessageViewProjection`
>
> We can reuse the same mechanism for other routes (we only need to
> write
> new bindings)
>
> (Not included in this explanation)
>
> Does it answers your questions?
Yes, very well. Thank you for the explanation.
> Does it look like a desirable solution?
Yes, I agree it's a good solution for this specific case and probably
for some other cases too.
--
Matthieu Baechler
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Webadmin modularity: action registration
Posted by Tellier Benoit <bt...@apache.org>.
On 02/12/2019 16:18, Matthieu Baechler wrote:
> Hi,
>
> Could you please give us a end-to-end example of what you describe?
>
I will give that below.
> How does a Task declare the endpoint it contribute to?
It takes a `Set<TaskRegistration>` with a @Named annotation for it as a
constructor parameter.
> How are conflicts managed?
Given the set of `TaskRegistration` register as stated above,
Then each Routes will build it's TaskFactory (local field initialized in
the constructor)
And have a precondition on distinct actions.
> Are routes modular or each endpoint can declare some point of
> extensions?
Each endpoint will have to declare it's own extensions.
Note that my proposal leverage the Task model we use on `POST` actions.
>
> Cheers,
>
Taking `POST /users/BOB/mailboxes` endpoint
UserMailboxes routes takes a Set<TaskRegistration> as a constructor
parameter annotated with @Named("allMailboxesTasks")
We write a task registration for user mailbox reIndexing (action
reIndex) generating the task to reIndex one mailbox.
We for user mailbox jmapView recomputation (action
recomputeJMAPFastMessageViewProjection) generating the task to recompute
JMAP fastMessageView projection.
Binding to TaskRegistration action reIndex can be done in
webadmin-guice-data.
Binding for TaskRegistration action
recomputeJMAPFastMessageViewProjection can be done in
webadmin-guice-data-jmap.
I can then be calling:
- `POST /users/BOB/mailboxes?task=reIndex`
- `POST /users/BOB/mailboxes?task=recomputeJMAPFastMessageViewProjection`
We can reuse the same mechanism for other routes (we only need to write
new bindings)
(Not included in this explanation)
Does it answers your questions?
Does it look like a desirable solution?
Benoit
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Webadmin modularity: action registration
Posted by Matthieu Baechler <ma...@apache.org>.
Hi,
Could you please give us a end-to-end example of what you describe?
How does a Task declare the endpoint it contribute to?
How are conflicts managed?
Are routes modular or each endpoint can declare some point of
extensions?
Cheers,
--
Matthieu Baechler
On Mon, 2019-12-02 at 14:33 +0700, Tellier Benoit wrote:
> Hi all,
>
> ## Context
>
> While contributing a way to rebuild JMAP fast messageView projection
> via
> webadmin, we end up with the need of supporting the following actions
> on
> the same endpoint:
>
> Example:
>
> POST /users/BOB/mailboxes?task=rebuildMessageFastViewProjection
> POST /users/BOB/mailboxes?task=reIndex
>
> ReIndexing is a task defined in mailbox-api that any backend relying
> on
> a message search index can rely on.
>
> rebuildMessageFastViewProjection is an action that only make sense
> for
> products shipping JMAP.
>
> We need a way to 'combine' both actions within one endpoint in a
> modular
> way.
>
> ## Proposal
>
> - Defining a `TaskRegistration` object:
>
> ```
> class TaskRegistration {
> private final TaskType taskType;
> private final TaskGenerator taskGenerator;
> }
>
> interface TaskGenerator {
> Task generate(Request request);
> }
> ```
>
> - Thus a @Named task factory can collect task registration for each
> one
> of these 03 endpoints, which can thus be defined in a modular way.
>
> - We can thus post ReIndexing to be using these taskDeclaration
>
> - And finally using them to add
> task=rebuildMessageFastViewProjection
> support to this endpoint.
>
> ## Consequence
>
> Each back-end can register the actions that make sense for it.
>
> We would furthermore ship a mechanism allowing a REST resource
> oriented
> mechanism that will prevent in the future the creation of RPC like
> endpoints.
>
> Would such a proposal make sense?
>
> Best regards,
>
> Benoit.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org