Hi Anton:

In message <trinity-d00a0ece-b2c8-45e0-bc65-77d8b1d41bc6-1716959364829@3c-app-m
ailcom-bs09>,
Anton Savchuk writes:
>> Umm, not really. You can have multiple cron jobs scheduled running
>> under one cron binary.
>
>Yes, we can have multiple cron jobs, but if we want to get
>credentials or time from somewhere else, we need to write another
>wrapper to configure the crontab.

True, but you are writing something in any case. Write a wrapper to
configure cron or you write a daemon to persistently poll for email.

>But mounting crontab using a docker/podman secret looks like a some
>solution. For example, it can be templated with Ansible.

Yup.

>> I'm not sure what you mean by asynchronous process. Do you mean the
>> ability to schedule each tracker separately?
>
>Something like a queue for each mailbox, independent of the others.

If you mean only allow one process to access a remote mailbox at a
time, yes I agree. Otherwise you have the possibility of processing a
message multiple times. Nobody want 10,000,000 issues because of a
spinning poller.

>> Not sure what you mean here. Would you create a new rest endpoint that
>> triggers mailgw when called?
>
>I think we have several implementation options that we can think about.
>
>For example, we can just create new issues using POST requests with
>authorization.

One issue with this is that the mailgw impersonates the email sender
inside of roundup. This is not supported over REST. It's not
impossible, but it is complex and would mean that at minimum you have
to:

  map email sender to a roundup user

  potentially create a new user (if allowed by config.ini)

  become the new user (maybe using a JWT) for multiple requests to
     create the issue and new messages, timelogs etc.

  handle all the options mailgw currently does -- dropping signatures,
     handling quoted material, prefix parsing to get the right issue
     to update etc.

and this is just 30 seconds of thought. I am sure there are a lot more
issues to deal with to create an email -> REST gateway that
reimplements roundup-mailgw.

>But in this case we need to process emails on the
>poller side.

The poller will always have to process the emails.
The question is how much processing.

>Another option is to have some endpoint that will accept the
>serialized messages from the poller and pass it to mailgw for
>processing.

You mean like smtp, or (using netcat)

  nc -p 2025 -l | roundup-mailgw /path/to/tracker

where the poller sends messages to port 2025 (or 25) serially or in
parallel.

>In this case, the poller must perform preprocessing to
>serialize emails.

The poller has to 'lock' the IMAP source, and trigger processing for
each email to make sure an email isn't procesed twice. But multiple
emails can be processed in parallel. Just depends on how you set up
your endpoint.

(IIRC, there is an outstanding request to have roundup-mailgw do it's
own locking so multiple mailgw pollers with the same options can't run
in parallel. It's not as simple as one mailgw poller per tracker as
you can have multiple email addresses per tracker which shouldn't
block each other.)

>> The docker image already supports number of subcommands (admin, shell,
>> demo ..). Adding one more for email would be possible.  Then you would
>> run the single docker image in two modes (and two containers). Default
>> mode (which runs roundup-server) and email mode which runs imapServer.
>
>Yes, that's an option. At least it requires a less work than in other
>cases.
>
>But maybe it would be nice to teach mailgw and trackers to
>communicate via REST API?

That would be tricky as I outline above. You could just connect to an
endpoint served up under /rest and post an email to it. The endpoint
will do all the work of roundup-mailgw. But that's not really
REST. It's really a remote procedure call at that point.

Have a great day.