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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
