> On 07/03/13 23:26, Giampaolo Tomassoni wrote: > > I see there would be problems in naming your project "RSA". > > Nevertheless, is there any plan to have the current rspamd features > > in a library, in order to allow third-parties to develop their own > > message handling interface wrapping it? > > At the moment, rspamd consist of several shared libraries (rspamd-util, > rspamd-mime and rspamd-server) and the main application logic (main > process + worker processes). However, without application logic there > is > no convenient way to use things, such as plugins or event loops. > Therefore, if you can give some concrete example of what functionality > should be used in such 3-rd parties applications I can provide more > details.
Something like Amavisd is a concrete example (http://www.ijs.si/software/amavisd/). It has many features working around SA which may somehow be replicated in a piece of code using an rspamd library. Also, what if someone wants to integrate your product into some kind of javamail server? (Apache James, in example http://james.apache.org) Yes, one can leverage the spamd-like rspamd's protocol, but this means a message have to be copied back and forth from different processes, result codes converted to ASCII and then re-interpreted back by some other process... There would probably be better performances by merging together software layers which have basically to cooperate anyway. Also, a library could expose a response object carrying many more information than the ones one can expose via a thin socket protocol. The main difficulties in a transition to a library model are in managing (loading) the configuration and in the event pump. I guess a good starting point would be to put the configuration parser and the event pump model in the rspamd application, while all other functionalities may be in the library. This way an application could even, say, store the configuration in a database instead that in an xml file, as well as adopt a different model then the event-based one. > Nevertheless, some features, including DKIM, SPF and other parsers are > worth to move them in some separate BSD licensed libraries for those > who want fast and lightweight support of these techniques. Right. There could even be an intermediate layer in the library, allowing a user to adopt its preferred DKIM/SPF implementation. This may even be true for DNS resolution (which basically means that is the user that chooses an event-based approach instead of a multithreaded or whatever one). Thanks, Giampaolo > > -- > Vsevolod Stakhov
