Search results for "jmap"

Re: v2.2.22 release candidate released

by Timo Sirainen

On 04 Mar 2016, at 17:40, Miquel van Smoorenburg <miquels(a)cistron.nl> wrote: > > Question: some time ago you mentioned that you were going to work on caldav/carddav support. What is the status of that, and will the calendar/contacts database be available over JMAP as well? Initially JMAP will be email-only. The CalDAV/CardDAV plans have been postponed for now.

9 years, 1 month

Re: v2.2.22 release candidate released

by Tom Sommer

On 2016-03-04 16:49, Timo Sirainen wrote: > On 04 Mar 2016, at 17:40, Miquel van Smoorenburg <miquels(a)cistron.nl> > wrote: >> >> Question: some time ago you mentioned that you were going to work on >> caldav/carddav support. What is the status of that, and will the >> calendar/contacts database be available over JMAP as well? > > Initially JMAP will be email-only. The CalDAV/CardDAV plans have been > postponed for now. Damn. I'd kill for a Dovecot-integrated/quality CalDAV-server.

9 years, 1 month

Re: Perl was: JMAP: Re: http API for IMAP

by Ralph Seichter

* Thomas Güttler via dovecot: > https://github.com/guettli/programming-guidelines#regex-are-great---but-its… Thanks for including the disclaimer "It's my personal opinion and feeling. No facts, no single truth." in your 'guidelines' (many of which I disagree with). I just wish you had included the same disclaimer in what you wrote in this thread, instead of presenting your personal opinions and beliefs as facts. Also, this has drifted far away from being related to Dovecot in any useful way. -Ralph

5 years, 5 months

jmap

by Maciej Milaszewski IQ PL

Hi Is there any chance that Dovecot-2.2.36 supports "jmap" ? -- Maciej Miłaszewski IQ PL Sp. z o.o. Starszy Administrator Systemowy Biuro Obsługi Klienta: e-mail: bok(a)iq.pl tel.: +48 58 326 09 90 - 94 fax: +48 58 326 09 99 Dział pomocy: https://www.iq.pl/pomoc Informacja dotycząca przetwarzania danych osobowych: https://www.iq.pl/kontakt Jakość gwarantuje: ISO 9001:2000 IQ PL Sp. z o.o. z siedzibą w Gdańsku (80-298), ul. Geodetów 16, KRS 0000007725, Sąd rejestrowy: Sąd Rejonowy w Gdańsku VII Wydział KRS, kapitał zakładowy: 140.000 PLN, NIP 5832736211, REGON 192478853

6 years, 2 months

Re: Foreman component

by Timo Sirainen

On 19 Apr 2016, at 12:55, Aki Tuomi <aki.tuomi(a)dovecot.fi> wrote: > > I am planning to add foreman component to dovecot core and I am hoping > for some feedback: > > Foreman - generic per-user worker handling component First an explanation of what this was planned to be used for: Think about many short-lived JMAP (HTTP) connections with each connection creating a new jmap process that opens the user's mailbox, processes the JMAP command, closes the mailbox and kills the process. Repeat for each command. Not very efficient when the same jmap process could handle all of the user's JMAP requests. The same problem exists also with most webmails' IMAP connections that are very short-lived. One annoying problem with the foreman concept is that it requires an open UNIX socket for all the worker processes. Which could mean >10k open UNIX sockets, which all too often runs into file descriptor limits. We could of course just increase it high enough, and it probably would work ok.. But I also hate adding more of these "master" processes because they don't scale easily to multiple CPUs so they might become bottlenecks at some point (and some of these existing master processes already have become bottlenecks). I've been trying to figure out a nice solution for the above problem for years already, but never really came up with anything better. Except today finally I had the new realization that anvil process already contains all of the needed information. We don't need a new process containing duplicated data, just some expansion of anvil and master. Of course, anvil is still kind of a "master" process that knows about all users, but it's already there anyway. And there's the new idea of how to avoid a single process using a ton of sockets: (Talking only about IMAP here for clarity, but the same applies to POP3, JMAP and others.) - Today anvil already keeps track of (user, protocol, imap-process-pid), which is where "doveadm who" gets the user list. - Today imap-login process already does anvil lookup to see if the user has too many open connections. This lookup could be changed to also return the imap-process-pid[] array. - We'll add a new feature to Dovecot master: Ability to specify service imap { unix_listener /var/run/dovecot/login/imap-%{pid} { .. } }, which would cause such a UNIX socket path to be dynamically created for each created process. Only that one process is listening in the socket, master process itself wouldn't keep it open. When the process gets destroyed, the socket gets deleted automatically. - When imap process starts serving an IMAP connection, it does fchmod(socket, 0) for its imap-%{pid} listener. When it stops serving an active IMAP connection it does fchmod(socket, original-permissions). - imap-login process attempts to connect to each imap-%{pid} socket based on the imap-process-pid[] list returned by anvil. It ignores each EACCES failure, because those are already serving IMAP connections. If it succeeds in connecting, it sends the IMAP connection fd to it. If not, it connects to the default imap socket to create a new process. - The above method of trying to connect to every imap-process-pid[] is probaly efficient enough, although it probably ends up doing a lot of unnecessary connect() syscalls to sockets that are already handling existing connections. If this needs to be optimized, we could also enhance anvil to keep track of the "does this process have an active connection" flag and it would only return imap-process-pid[] for the processes without an active connection. There are of course some race conditions with this in any case but the worst that can happen is that a new imap process is created when there was another existing one already that could have served the connection, so slightly worse performance in some rare situations. These same per-process sockets might be useful for other purposes too.. I've many times wanted an ability to communicate with an existing process. The "ipc" process was an attempt to do something about it, but it's not very nice and has the same problems with potentially using a huge number of fds. Then there's the issue of how the management of idle processes (= processes with no active IMAP connections) goes: - service { idle_kill } already specifies when processes without clients are killed. We can use this here as well, so when IMAP connection has closed the process stays alive for idle_kill number of seconds until it gets closed. - If idle_kill times are set large enough on a busy system, we're usually reaching service { process_limit } constantly. So when no new processes can be created, we need the ability to kill an existing process instead. I think this is master process's job. When connection comes to "imap" and process_limit is reached, master picks the imap process with the longest idle-time and kills it (*). Then it waits for it to die and creates a new process afterwards. There's race condition here though and the process may not die but instead notify master that it's serving a new client. In this case master needs to retry with the next process. The process destroying might also not be fast always. To avoid unnecessarily large latencies due to waiting for process destruction, I think master should always try to stay a bit below process_limit (= a new service setting). - (*) I'm not sure if longest idle-time is the ideal algorithm. Some more heuristics would be useful, but this complicates master process too much. The processes themselves could try to influence master's decisions with some status notifications. For example if we've determined that user(a)example.com constantly logs in every 5 minutes, and the process has been idle for 4mins59 seconds, which is also the oldest idling process, we still don't want to kill it because we know that it's going to be recreated in 1 second anyway. This is probably not going to be in the first version though.

8 years, 11 months

Re: Perl was: JMAP: Re: http API for IMAP

by Thomas Güttler

Am 18.11.19 um 16:18 schrieb Ralph Seichter via dovecot: > * Thomas Güttler via dovecot: > >> https://github.com/guettli/programming-guidelines#regex-are-great---but-its… > > Thanks for including the disclaimer "It's my personal opinion and > feeling. No facts, no single truth." in your 'guidelines' (many of which > I disagree with). I just wish you had included the same disclaimer in > what you wrote in this thread, instead of presenting your personal > opinions and beliefs as facts. > > Also, this has drifted far away from being related to Dovecot in any > useful way. You disagree? Great! I am curious. What is wrong in my personal guidelines? Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines

5 years, 4 months

Re: Perl was: JMAP: Re: http API for IMAP

by Jean-Daniel

> Le 19 nov. 2019 à 09:14, Thomas Güttler via dovecot <dovecot(a)dovecot.org> a écrit : > > Am 18.11.19 um 16:18 schrieb Ralph Seichter via dovecot: >> * Thomas Güttler via dovecot: >>> https://github.com/guettli/programming-guidelines#regex-are-great---but-its… >> Thanks for including the disclaimer "It's my personal opinion and >> feeling. No facts, no single truth." in your 'guidelines' (many of which >> I disagree with). I just wish you had included the same disclaimer in >> what you wrote in this thread, instead of presenting your personal >> opinions and beliefs as facts. >> Also, this has drifted far away from being related to Dovecot in any >> useful way. > > > You disagree? Great! I am curious. What is wrong in my personal > guidelines? Please, if you want to start a coding style flame war, do that in private. I think we got enough mails from this this discussion that are completely off the dovecot list subject.

5 years, 4 months

Re: RFC: HTTP based storage API

by Timo Sirainen

On 08 Feb 2016, at 11:01, Nagy, Attila <bra(a)fsn.hu> wrote: > > Hi, > > Nearly every popular programming language has an LMTP/POP/IMAP implementation, most of them suck in many different ways. > I don't know any server or library which provides a well-established, compatible protocol frontend with an open backend API, which could be used to easily make a custom storage backend for the LMTP/POP/IMAP frontend in any language, in any programming paradigm, irregardless of the frontend implementation. > > Dovecot is very close to this: it speaks IMAP to the backend, but you still have to make a nearly complete IMAP implementation, which is a PITA. > > Therefore I am curious about your opinion: what about an HTTP-based open backend (lib-storage) API to Dovecot? We're planning on implementing http://jmap.io/ to Dovecot v2.3. It's close enough to how Dovecot works internally (although we'd still need the threading support) and also at least attempting to become a standard. We haven't really started it yet though, so now would be a good time to give any alternative suggestions or complaints about jmap :)

9 years, 2 months

Re: JMAP support in Dovecot

by WJCarpenter

Bron Gondwana wrote on 11/27/2016 02:25 PM: > The demo proxy was a pretty quick hack and isn't very efficient, but > it should be working. It does a fairly slow background import for > existing accounts, so I'd recommend using small tests accounts. What > particular bit is broken for you? (apart from the known not-working > authentication flow) Bron. I don't know what you mean by the "known not working authentication flow", so possibly that is what I am hitting. On the "Set Hosts" screen with either Chrome or FireFox, I see two boxes each for IMAP and SMTP and a drop-down to toggle plaintext, SSL, or STARTLS. The fields are populated initially with "IMAP: 993/1/SSL" and "SMTP: 587/1/STARTLS". I don't know what that "1" is supposed to mean, so I replaced it with the relevant server names. I got an error "UNABLE TO CONNECT for <the email address I used>". To try again, I swapped those two fields around. Same result. (I was watching my server logs at the same time and saw no connection attempts.) I could not figure out how to go further.

8 years, 4 months

Re: RFC: HTTP based storage API

by lst_hoe02＠kwsoft.de

Zitat von Timo Sirainen <tss(a)iki.fi>: > On 08 Feb 2016, at 11:01, Nagy, Attila <bra(a)fsn.hu> wrote: >> >> Hi, >> >> Nearly every popular programming language has an LMTP/POP/IMAP >> implementation, most of them suck in many different ways. >> I don't know any server or library which provides a >> well-established, compatible protocol frontend with an open backend >> API, which could be used to easily make a custom storage backend >> for the LMTP/POP/IMAP frontend in any language, in any programming >> paradigm, irregardless of the frontend implementation. >> >> Dovecot is very close to this: it speaks IMAP to the backend, but >> you still have to make a nearly complete IMAP implementation, which >> is a PITA. >> >> Therefore I am curious about your opinion: what about an HTTP-based >> open backend (lib-storage) API to Dovecot? > > We're planning on implementing http://jmap.io/ to Dovecot v2.3. It's > close enough to how Dovecot works internally (although we'd still > need the threading support) and also at least attempting to become a > standard. We haven't really started it yet though, so now would be a > good time to give any alternative suggestions or complaints about > jmap :) That would be a cool feature, Thanks. Andreas

9 years, 2 months

Search results for query "jmap"