Subkismet Architecture and Structure

Coordinator
Jun 22, 2007 at 8:04 AM
Edited Jun 22, 2007 at 8:05 AM
Copy/Pasted from our private email discussions with Phil and Thommi:

I saw the code for the main Subkismet library. Since Subkismet wants to be a library (or a framework?) to block spams, there are some points that I’ve seen in the architecture and code structure. Implementations are based on interfaces (i.e. IComment and Comment) which can limit us in further developments. From a framework point of view I’d like to suggest that replace these interfaces with base classes or abstract base classes which are more open for extensibility.

My suggestion is to replace IComment with a Post base class (since we’re blocking forum spams or any other spam type, this name is suitable though) then derive some classes like Comment, Trackback and Pingback from this base class and provide appropriate properties/method overloads to work with them. I think this is a good change to make Subkismet a framework.

On the other hand, we can replace some classes like IAkismet with an abstract base class like AkismetBase and derive our logic class from this base class because it helps us to adapt/extend our code for newer API specification from Akismet, Google or … This is already done for Captcha in Subkismet.

And the last point is about the structure of classes and namespaces. I see that Akismet classes are located at root but Captcha classes are moved to their own namespace. I (and probably Thommi) would like to create our new project in a namespace as well, so IMO it’s better to move some classes (i.e. Akismet) from the root to a new namespace.

However, above points were just to have a consistency between different pieces of Subkismet and make it a good framework. I hope you give some feedbacks on them.
Coordinator
Jun 22, 2007 at 8:30 AM
Abstract Base Classes? Sounds good. As long as we always have one default implementation that users can just use if they don’t need to customize it.

In all cases, I want this to work out of the box for the 80% scenarios, but support the 20% scenarios via abstract base classes.

Re: Namespaces: Agreed. We should move the Akismet stuff into a more generic namespace than Akismet though. Maybe “Services”? The idea is that someday, someone might build a competitor to Akismet. Akismet to be is a spam filter web service. Someday, Subkismet might even be that competitor. ;)

As for IComment, this is specific to Akismet. PostBase is fine, but deriving the other classes seems like overkill because the only difference between these things as far as Akismet is concerned is one field which takes in a string. To Akismet, everything is a “comment” and you can specify a CommentType which is a string rather than enum because you can make it anything you want. I think they do some sort of grouping internally.

Maybe we just call it AkismetPostBase and have a simple concrete implementation called AkismetPost.