Search results for "jmap"

Re: JMAP support in Dovecot

by Mike Gao

Hi, Any news for jmap Support in Dovecot? Thanks, Mike

6 years, 3 months

Re: JMAP support?

by Leonardo Rodrigues

Em 08/03/2021 16:43, @lbutlr escreveu: > On 08 Mar 2021, at 02:15, Mark Constable <markc(a)renta.net> wrote: > There doesn't seem to be much interest in JMAP ou there, which means it is going to be pretty hard to get something working well unless you write it yourself. > > Or sponsor its development, if the OP is so interested on it! -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email gertrudes(a)solutti.com.br My SPAMTRAP, do not email it

5 years, 1 month

Re: JMAP support?

by ＠lbutlr

On 08 Mar 2021, at 14:04, Leonardo Rodrigues <leolistas(a)solutti.com.br> wrote: > Em 08/03/2021 16:43, @lbutlr escreveu: >> On 08 Mar 2021, at 02:15, Mark Constable <markc(a)renta.net> wrote: >> There doesn't seem to be much interest in JMAP ou there, which means it is going to be pretty hard to get something working well unless you write it yourself. > Or sponsor its development, if the OP is so interested on it! I checked and Roundcube-next appears to be a dead project, so I'd really not hold out much hope. -- NO ONE WANTS TO HEAR ABOUT MY SCIATICA Bart chalkboard Ep. AABF09

5 years, 1 month

Re: JMAP support?

by julio covolato

Em 09/03/2021 05:43, Jean-Daniel escreveu: Hi. > The HTTP API is just for doveadm and is not related in anyway to JMAP AFAIK. Are there any web-admin for dovecot/doveadm? Thanks ---------------------------------- _ Engº Julio Cesar Covolato 0v0 <julio(a)psi.com.br> /(_)\ F: 55-11-99175-9260 ^ ^ PSI INTERNET ----------------------------------

5 years, 1 month

JMAP Support Status

by David Klingenberg

Hello, what is the current status of JMAP support in Dovecot? Is it already supported or is there any ongoing work on it? I have found some older threads mentioning it as planned, but they are quite old and I haven't found anything new on that topic. Best Regards, David

4 years, 8 months

Re: JMAP Support Status

by Benny Pedersen

On 2022-04-15 16:03, @lbutlr wrote: >> cyrus-imapd have it > But only cyrus, I believe. > If you ask most nerds what JMAP is, they'll talk about java, not IMAP. +1, we both wait for dovecot or change to cyrus :=) i feel cyrus is more stable then dovecot, atleast for the free version of dovecot, for dovecot-pro i dont know yet :/ my constructive cretik would be to see wiki have full dokumention of how to configure all detail in dovecot, eq nothing is left to be figured out of admins that install dovecot for the first time, again dovecot v1 is more stable then dovecot v2, i know others say you are kidding, nope

4 years

Re: RFC: HTTP based storage API

by Timo Sirainen

> On 08 Feb 2016, at 11:59, Timo Sirainen <tss(a)iki.fi> wrote: > > 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 :) Oh, you were thinking about ability to provide IMAP/etc support for other random servers, and have Dovecot act as kind of a middleware and translate the requests. Maybe the answer is still jmap though? It would require jmap lib-storage backend similar to imapc, which would be doable, although not really something we're right now planning to implement.

10 years, 2 months

Re: v2.2.22 release candidate released

by Miquel van Smoorenburg

On 04/03/16 14:33, Timo Sirainen wrote: > There are some larger changes here, especially to doveadm to make it > support HTTP API. There's still time to do smaller tweaks to the API, > so let us know if you have some improvement ideas. Note that the API > was designed to look mostly like JMAP, which we're planning to > implement also for v2.3. The plan is to fork v2.3 development tree > soon. Let me say that I think it's really cool that you're adding support for JMAP. This will make it possible for front-end developers to build webmail or mail-aware applications right on top of dovecot, instead of first having to build a server-side middleware layer between IMAP and the application. 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? Thanks, Mike.

10 years, 1 month

Re: RFC: HTTP based storage API

by Timo Sirainen

> On 08 Feb 2016, at 13:28, Nagy, Attila <bra(a)fsn.hu> wrote: > > On 02/08/16 12:07, Timo Sirainen wrote: >> On 08 Feb 2016, at 12:56, Nagy, Attila <bra(a)fsn.hu> wrote: >>> On 02/08/16 11:16, Timo Sirainen wrote: >>>> Oh, you were thinking about ability to provide IMAP/etc support for other random servers, and have Dovecot act as kind of a middleware and translate the requests. Maybe the answer is still jmap though? It would require jmap lib-storage backend similar to imapc, which would be doable, although not really something we're right now planning to implement. >>>> >>> Yeah, the opposite, in this case a jmap backend to Dovecot. >>> BTW, I think jmap is too high level and implementing a jmap server is very much like implementing an IMAP one. >>> >>> I much more think of a pluggable, easy (remote) storage API, which has much less to do with IMAP, but can offer capabilities, which can help Dovecot (like the search and indexes). >> What kind of use cases are you thinking for this remote storage API? What kind of remote storages would implement it, and what kind of installations would use them? >> > Interfacing non-email systems to e-mail protocols and implementing other storage options (I can't say a better analogue than what FUSE is). > Using Dovecot as a protocol implementation, but not for the underlying storage method, which may be custom to the given solution. > A flexible way of implementing and adapting anything to IMAP. > > For example if I want to store really old and archived e-mails in a costly compression format somewhere in the cloud, but hot mails locally, based on my custom policies. > In an international company there may be some regulations about what should go where, so for example if I can handle object placement myself, I can use the same installation to store non-EU mails in non-EU countries and others in US or EU clouds if law permits. You could already implement these with mail-filter plugin. The locally stored mail would be just an object pointer, which the mail-filter plugin reads from the remote storage. Although I think mail-filter is lacking error handling right now. > Intermixing several systems into one (like merging two IMAP accounts into one) etc. If I bothered to implement per-namespace imapc-settings, this could be done with virtual plugin. > Some of these are very costly to develop in Dovecot, while just a few lines in -say- Python or go. I think it might not be that easy. Although I've made lib-storage backends easier and easier to implement, it's still not exactly trivial. Implementing it behind some API could simplify it somewhat, but it wouldn't really remove all the difficult work that needs to be done. For example some backends might want to be read-only, others read-write. Some might want Dovecot to store all the message flags and other metadata locally, while others might want to store it themselves (and that would require two-way syncing between them). Some backends would support searching, fetching some headers fast and in general support different kinds of optimizations, while others wouldn't. The imapc backend is of course already implementing a lot of this functionality, but it's also getting complex. The backend would also have to guarantee some things to be compatible with IMAP, mainly never modifying existing mails. One alternative might be to add scripting support to Dovecot. I've been thinking about that several times over the years. So instead of implementing plugins with C, you could implement them with Python or some other language. Long time ago I tried to do this with SWIG, but it didn't work out. The main problem was function pointers in structs, but nowadays those aren't directly called and I think it could be implemented a bit differently.

10 years, 2 months

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.

10 years, 1 month

Search results for query "jmap"