Peter Lindgren writes:
> H, there are more things in IMAP than just this. Mail clients (user
> agents) that are independent of the server platform, for instance.
I don't understand what you mean. Nothing I've said implies a dependence
on the server platform. The presentation of the hierarc
Timo Sirainen writes:
> I do kind of like that idea, but I don't really se how it would be
> practical here, especially if high performance is wanted.
I don't really see why a priori it would be any less performant than any
other particular RPC mechanism.
> 1. I'm not implementing Dovecot to Pl
On Jun 2, 2009, at 11:39 AM, pod wrote:
Timo Sirainen writes:
The big problem is what the protocol should be. Use some existing RPC
protocol? It should be something extensible so that a plugin in imap
process can talk to a plugin in storage process, without the base
processes knowing anything
pod skrev:
It's probably worth noting the irony, given this is a maillist about
Dovecot, in that this approach almost obsoletes the need for an IMAP
protocol in the first place (the upas/fs style layout as documented
doesn't really provide sufficient support for server side search for
example).
Timo Sirainen writes:
> The big problem is what the protocol should be. Use some existing RPC
> protocol? It should be something extensible so that a plugin in imap
> process can talk to a plugin in storage process, without the base
> processes knowing anything about the details (e.g. imap-quota
> "Protocol buffers are Google's ... blah-blah-blah ... using a variety of
> languages - Java, C++, or Python."
>
> I can't find good old plain C in this "variety of languages" :(
>
Protocol buffers is flexible message format specification, there are
plenty implementations of it , including C base
Timo Sirainen skrev:
The big problem is what the protocol should be. Use some existing RPC
protocol? It should be something extensible so that a plugin in imap
process can talk to a plugin in storage process, without the base
processes knowing anything about the details (e.g. imap-quota plugin
On Wednesday 27 May 2009 20.14.01 Aria Stewart wrote:
> > The big problem is what the protocol should be. Use some existing
> > RPC protocol? It should be something extensible so that a plugin in
> > imap process can talk to a plugin in storage process, without the
> > base processes knowing anythi
The big problem is what the protocol should be. Use some existing
RPC protocol? It should be something extensible so that a plugin in
imap process can talk to a plugin in storage process, without the
base processes knowing anything about the details (e.g. imap-quota
plugin asking quota us
On 147, 05 27, 2009 at 01:31:41PM +0400, Max Ivanov wrote:
> > The big problem is what the protocol should be. Use some existing RPC
> > protocol? It should be something extensible so that a plugin in imap process
> > can talk to a plugin in storage process, without the base processes knowing
> > a
> The big problem is what the protocol should be. Use some existing RPC
> protocol? It should be something extensible so that a plugin in imap process
> can talk to a plugin in storage process, without the base processes knowing
> anything about the details (e.g. imap-quota plugin asking quota usag
Timo Sirainen schrieb:
>
>
> 3. Mail processes talk to storage processes via some protocol. They
> can talk via UNIX socket or TCP/IP. If an existing connection can't
> handle the target UID, a new connection is made that either reuses an
> existing storage proces or creates a new one.
>
This sound
I just had a thought. It's probably going to be too big of a change
for v2.0, so something to think about for v3.0:
Supporting multiple UIDs is difficult. Currently expire-tool and
v2.0's LMTP server are implemented in a way that it's always running
as root and only temporarily dropping pri
13 matches
Mail list logo
