Hi Stefan! Thank you for your response.
Stefan Guerra wrote:
> when we discussed this architectural issue, we decided to have the
> decisor as a separate component, just like all the other filters,
> becouse this would have opened an easy way to use different filtering
> logics. For instance, a simple rule based one or a bayesian one, or even
> more complex decision systems. If anyone would have liked to change the
> decision logics, he/she had only to plug in a new decisor component
> respecting the communication grammar with the monitor. Moreover, as you
> know the monitor was a piece of work of Basile, who was the only one in
> the team to master the OCAML language, while the decisor was mostly a
> work of the META people. And no one wanted to put hands on in the OCAML
> code. That's it, probably Mohamed might want to comment it. By the way,
> I still think that the architectural point is still a good one.
Allowing the Poesia software to integrate a pluggable decision mechanism
is a good idea. But the way to implement it could be different: For
example, we can configure the monitor to load a Java class that
implements the decision algorithm, like a servlet on a Tomcat server.
Changing the decision is as simple as writing a java class and configure
the XML file of the monitor with it. IMHO, this way is more powerfull
than exporting the scores to an external process, because of the
protocol overhead of the second solution.
An other argument for using the monitor as a decision box is that it is
central in the Poesia architecture. It gets ICAP requests, scores from
the filters, and it is also a http client and it can download extra web
contents closely related to the filtered content, like a google search,
or the pages referenced by the web site... So it is the most appropriate
place to take the decision.
A third argument is simplicity. Integrating the decision in the monitor
will simplify the system and make it easier to maintain and to debug...
Now, I'm planning to release a third alpha with the new monitor and the
image filter, with a simple threshold rule. We have enough time to
continue the discussion before I integrate the decision mechanism. In my
opinion,the fourth alpha will integrate most of the filters but still
not the decision.
A last point I would like to discuss is the poesia loader. In my
opinion, we should separate the loader from the monitor. The loader
means for me a simple and reliable script that starts the monitor, the
proxy and the filters and restarts any component that craches. I think
tha the Linux inittab is a good candidate for this job...