[Dovecot] busy / developers documentation
Just thought I'd mention that I probably won't be answering mails very actively this week while I'm in San Antonio (and I was kind of busy last week too). Hopefully I'll get back to answering/bugfixing next week..
I also started writing developers documentation to http://wiki.dovecot.org/Design. Comments welcome. Some things I had planned next:
- istream internals
- lib-storage API docs
- ..?
Timo Sirainen wrote:
Just thought I'd mention that I probably won't be answering mails very actively this week while I'm in San Antonio (and I was kind of busy last week too). Hopefully I'll get back to answering/bugfixing next week..
I also started writing developers documentation to http://wiki.dovecot.org/Design. Comments welcome. Some things I had planned next:
- istream internals
- lib-storage API docs
- ..?
Excellent opportunity to post a similar message of my own. I'm quite suddenly involved in a civil rental dispute, resulting in a summary procedure (lawsuit) next week. This means that I'll be busy handling this for the moment.
Regards,
Stephan.
While you're in the neighborhood you should vist College Station and Austin. --David.
On Tue, 1 Dec 2009 17:39:55 -0600 Timo Sirainen tss@iki.fi wrote:
Just thought I'd mention that I probably won't be answering mails very actively this week while I'm in San Antonio (and I was kind of busy last week too). Hopefully I'll get back to answering/bugfixing next week..
I also started writing developers documentation to http://wiki.dovecot.org/Design. Comments welcome. Some things I had planned next:
- istream internals
- lib-storage API docs
- ..?
-- David Brown david@davidwbrown.name
I'm probably going to Austin on Thursday. No idea what College Station is or why I should go there :)
On Dec 1, 2009, at 9:33 PM, David Brown wrote:
While you're in the neighborhood you should vist College Station and Austin. --David.
On Tue, 1 Dec 2009 17:39:55 -0600 Timo Sirainen tss@iki.fi wrote:
Just thought I'd mention that I probably won't be answering mails very actively this week while I'm in San Antonio (and I was kind of busy last week too). Hopefully I'll get back to answering/bugfixing next week..
I also started writing developers documentation to http://wiki.dovecot.org/Design. Comments welcome. Some things I had planned next:
- istream internals
- lib-storage API docs
- ..?
-- David Brown david@davidwbrown.name
On Tue, Dec 01, 2009 at 05:39:55PM -0600, Timo Sirainen wrote:
Just thought I'd mention that I probably won't be answering mails very actively this week while I'm in San Antonio (and I was kind of busy last week too). Hopefully I'll get back to answering/bugfixing next week..
I also started writing developers documentation to http://wiki.dovecot.org/Design. Comments welcome. Some things I had planned next:
- istream internals
- lib-storage API docs
- ..?
Hello Timo,
Just an idea talking about writing documentation :
When I looked at the authentication code (using LDAP) back in the 1.1 version, it took me some time to understand the function call cascading, especially with the "callback"/"context" mechanism which I found clever but hard to follow.
I came to the understanding (hope I was right) that you were using some kind of layered architecture, which went something like this :
"low level" < ldap_request level < passdb_ldap_request level < auth_request level < auth_request_handler level < auth_client_connection level < "high level"
where :
. passdb_ldap_request == passwd checking
. auth_request == parameters (user, password, state) and internal management of the request
. auth_request_handler == building of the answer of the request
. auth_client_connecion == sending to the authentication client (imap-login)...
. callback : a pointer in a lower level to a function in an higher level
. context : what links "objects" of those layers eachother
I was thinking that, if my understanding is correct, some overview from you of such an architecture would be of great help for those who want to understand the code.
Thanks.
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Ter, 2009-12-01 at 17:39 -0600, Timo Sirainen wrote:
I also started writing developers documentation to http://wiki.dovecot.org/Design. Comments welcome. Some things I had planned next:
- istream internals
- lib-storage API docs
- ..?
Great stuff. Many thanks.
-- Jose Celestino SAPO.pt::Systems http://www.sapo.pt --------------------------------------------------------------------- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.
On Dec 1, 2009, at 6:39 PM, Timo Sirainen wrote:
Just thought I'd mention that I probably won't be answering mails
very actively this week while I'm in San Antonio (and I was kind of
busy last week too). Hopefully I'll get back to answering/bugfixing
next week..
Have a good trip!
I also started writing developers documentation to http:// wiki.dovecot.org/Design. Comments welcome. Some things I had
planned next:
- istream internals
- lib-storage API docs
- ..?
This is great news, thanks! One thing in particular that I'd like
to see is something on writing plugins. I have several ideas of
plugins I'd like to write but have hesitated to get started due to
not wanting to basically dig through tons of source to figure out how
to interface to Dovecot's internals.
-Dave-- Dave McGuire Port Charlotte, FL
On Dec 2, 2009, at 12:27 PM, Dave McGuire wrote:
I also started writing developers documentation to http://wiki.dovecot.org/Design. Comments welcome. Some things I had planned next:
- istream internals
- lib-storage API docs
- ..?
This is great news, thanks! One thing in particular that I'd like to see is something on writing plugins. I have several ideas of plugins I'd like to write but have hesitated to get started due to not wanting to basically dig through tons of source to figure out how to interface to Dovecot's internals.
The plugin API itself is really really simple. Basically Dovecot just calls plugin_name_init() and you'll go on from there. What would you want your plugin to do? Probably what you need is lib-storage API docs. There are a couple of hooks that only plugins use, but those still belong to lib-storage API category I think.
On Dec 2, 2009, at 4:39 PM, Timo Sirainen wrote:
I also started writing developers documentation to http:// wiki.dovecot.org/Design. Comments welcome. Some things I had
planned next:
- istream internals
- lib-storage API docs
- ..?
This is great news, thanks! One thing in particular that I'd
like to see is something on writing plugins. I have several ideas
of plugins I'd like to write but have hesitated to get started due
to not wanting to basically dig through tons of source to figure
out how to interface to Dovecot's internals.The plugin API itself is really really simple. Basically Dovecot
just calls plugin_name_init() and you'll go on from there. What
would you want your plugin to do? Probably what you need is lib- storage API docs. There are a couple of hooks that only plugins
use, but those still belong to lib-storage API category I think.
Actually my current ideas have nothing to do with storage; I want
to be able to access messages (including body text) during the
delivery process.
-Dave-- Dave McGuire Port Charlotte, FL
On Dec 2, 2009, at 4:50 PM, Dave McGuire wrote:
Actually my current ideas have nothing to do with storage; I want to be able to access messages (including body text) during the delivery process.
It's possible that you still should be using lib-storage to do whatever you wanted to do, because the incoming message gets put into internal "raw storage". But then again, maybe you need to do something similar to Sieve and set deliver_mail variable to point to your own function (and then call the original if necessary).
On Dec 2, 2009, at 6:54 PM, Timo Sirainen wrote:
Actually my current ideas have nothing to do with storage; I want
to be able to access messages (including body text) during the
delivery process.It's possible that you still should be using lib-storage to do
whatever you wanted to do, because the incoming message gets put
into internal "raw storage". But then again, maybe you need to do
something similar to Sieve and set deliver_mail variable to point
to your own function (and then call the original if necessary).
Hmm, ok. I'll go over the docs.
-Dave-- Dave McGuire Port Charlotte, FL
participants (6)
-
Dave McGuire
-
David Brown
-
Jose Celestino
-
Stephan Bosch
-
Thomas Hummel
-
Timo Sirainen