Re: [Dovecot] IMAP aggregation and MUPDATE protocolo
(Second time already within a few days when I accidentally hit reply rather than reply-to-all and then wonder why the message isn't showing up.)
On 24.11.2010, at 14.16, Ernesto Revilla Derksen wrote:
We're trying to find a solutions for aggregating data from several backends which are:
- normal mail IMAP
- repositories like Alfresco which offer an IMAP view for repository documents
I'm planning on implementing "IMAP client" backend for lib-storage, which means you could create namespaces that are proxied to remote IMAP server. Or even make Dovecot act as a caching IMAP proxy for your real IMAP server.
- issue trackers (issue + attachmentes + timeline)
I guess it could be possible to implement lib-storage backend for these too. :) Or maybe create some new simpler protocol that you can easily implement for them, and then create a lib-storage backend for that.
Timo Sirainen wrote:
I'm planning on implementing "IMAP client" backend for lib-storage, which means you could create namespaces that are proxied to remote IMAP server. Or even make Dovecot act as a caching IMAP proxy for your real IMAP server.
This would allow for some amazing setups.
I'm planning on implementing "IMAP client" backend for lib-storage, which means you could create namespaces that are proxied to remote IMAP server. Or even make Dovecot act as a caching IMAP proxy for your real IMAP server.
Yes, yes --- YEEEESSSS, please!!! :-)
ClemensHi.
2010/11/24 Clemens Schrimpe csch@kiez.net:
I'm planning on implementing "IMAP client" backend for lib-storage, which means you could create namespaces that are proxied to remote IMAP server. Or even make Dovecot act as a caching IMAP proxy for your real IMAP server.
Yes, yes --- YEEEESSSS, please!!! :-)
Clemens
Indeed, this sounds very interesting. I would be interested in this "...proxied to remote IMAP server" stuff.
Namespace to imap server mapping would be perfect.
What we've already accomplished is do it inside a REST interface to aggregate several IMAP accounts, but we would like to have a proof of concept for IMAP aggregation. I couldn't find any solution, beside Cyrus-Murder, so I concluded that I was on the bad way, and perhaps should do the aggregation stuff at REST, Atom/RSS/Activity Feed level, much like fuser.com, or just sync activity feeds with something like feed2imap.
Is IMAP aggregation proxying really so difficult? I know about the problems of COPY (which in some cases in Cyrus-Murder is handled by the proxy itself), but don't know if there are any other gotchas.
Regards. Erny
-- Ernesto Revilla Yaco Sistemas +34 954 500 057
On Thu, 2010-11-25 at 00:43 +0100, Ernesto Revilla Derksen wrote:
Is IMAP aggregation proxying really so difficult? I know about the problems of COPY (which in some cases in Cyrus-Murder is handled by the proxy itself), but don't know if there are any other gotchas.
Are you thinking about simple proxying, so that if you switch to mailbox1 it would do a connection to server1 which would completely handle it, so that until next SELECT/EXAMINE is done the proxy would just do dummy proxying?
Maybe something like that would work, but I'm not very interested in doing it. Also it would limit some features that could be made available (e.g. virtual mailboxes wouldn't work with it). There are many more interesting things that can be done with a smarter proxy.
Hi again.
Pls, see below.
2010/11/26 Timo Sirainen tss@iki.fi:
On Thu, 2010-11-25 at 00:43 +0100, Ernesto Revilla Derksen wrote:
Is IMAP aggregation proxying really so difficult? I know about the problems of COPY (which in some cases in Cyrus-Murder is handled by the proxy itself), but don't know if there are any other gotchas.
Are you thinking about simple proxying, so that if you switch to mailbox1 it would do a connection to server1 which would completely handle it, so that until next SELECT/EXAMINE is done the proxy would just do dummy proxying? Well, this may not be enough.
Maybe something like that would work, but I'm not very interested in doing it. Also it would limit some features that could be made available (e.g. virtual mailboxes wouldn't work with it). There are many more interesting things that can be done with a smarter proxy.
One thing we would like to have a powerful search engine, so that a user could locate any message, document, etc. that he/she has access to. The searches may be split between all backends, and the front-end would aggregate search results.
Yes, we would be very interested in that libstorage thing. Our initial backends are Dovecot, Alfresco and an issue tracker, like Redmine. The issue tracker has actually NO IMAP interface. But perhaps we could offer a libstorage provider or a feed like Activity Feed, etc.
Could you give us a rough estimate of how many workin hours or days this could take? We'd need at least an pure imap aggregator and then we could talk about other converters.
Beside this, I'm still in doubt about if we're on the correct way of unifying information of different sources.
Best regards. Erny
On 9.12.2010, at 23.41, Ernesto Revilla Derksen wrote:
Yes, we would be very interested in that libstorage thing. Our initial backends are Dovecot, Alfresco and an issue tracker, like Redmine. The issue tracker has actually NO IMAP interface. But perhaps we could offer a libstorage provider or a feed like Activity Feed, etc. .. Beside this, I'm still in doubt about if we're on the correct way of unifying information of different sources.
I wonder if there would be a way for the services without IMAP interface to provide something really simple that Dovecot could use. If there are not a huge number of items ("mails") then it would work to simply have a POP3 UIDL style list and an ability to download an item by the UIDL. If there is a huge number of items, then maybe something extra where you can ask it to send only new items since last check (maybe "sent anything new since UIDL asdf"). I haven't really looked at RSS/Atom, maybe those would be enough for this?
Then this interface could be implemented for issue trackers etc. and Dovecot could have an optimized lib-storage interface for it.
participants (4)
-
Clemens Schrimpe
-
Ernesto Revilla Derksen
-
Timo Sirainen
-
Willie Gillespie