Zend Framework: Zend_Service_TypePad_AntiSpam Component Proposal
| Proposed Component Name | Zend_Service_TypePad_AntiSpam |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Service_TypePad_AntiSpam |
| Proposers | Jordan Ryan Moore |
| Zend Liaison | TBD |
| Revision | 1.0 - 30 May 2008: Initial Draft. (wiki revision: 10) |
Table of Contents
1. Overview
Zend_Service_TypePad_AntiSpam provides a simple interface for interacting with the TypePad AntiSpam API. Zend_Service_TypePad_AntiSpam provides a REST-based service for checking comment spam and reporting spam and ham (non-spam) comments. A rewrite of Zend_Service_Akismet internals will be necessary to make it more extensible.
2. References
3. Component Requirements, Constraints, and Acceptance Criteria
- This component will modify Zend_Service_Akismet to be more extensible.
- This component will not modify the API of current public Zend_Service_Akismet methods.
- Zend_Service_TypePad_AntiSpam will extend Zend_Service_Akismet.
- Zend_Service_TypePad_AntiSpam will not provide additional functionality that is not available in Zend_Service_Akismet.
4. Dependencies on Other Framework Components
- Zend_Http_Client
- Zend_Service_Abstract
- Zend_Service_Akismet
- Zend_Service_Exception
- Zend_Version
5. Theory of Operation
A Zend_Service_TypePad_AntiSpam object is instantiated with an API key and blog URL. After that, the developer need only call one of the API methods, each of which returns a boolean.
6. Milestones / Tasks
- Milestone 1: Proposal published
- Milestone 2: Proposal accepted
- Milestone 3: Working code and unit tests checked into incubator
- Milestone 4: Documentation checked into incubator
7. Class Index
- Zend_Service_Akismet
- Zend_Service_TypePad_AntiSpam
8. Use Cases
| UC-01 |
|---|
| UC-02 |
|---|
| UC-03 |
|---|
| UC-04 |
|---|
| UC-05 |
|---|
9. Class Skeletons
My reasoning for having Zend_Service_TypePad_AntiSpam extend Zend_Service_Akismet was to reduce code duplication. I'm realizing that this was a poor design decision.
On the other hand, your suggestion to create an abstract class that they both extend would probably have the same flaws. What methods would you suggest defining and/or implementing in the abstract class?
The more I think about it, the more I'm leaning towards Zend_Service_TypePad_AntiSpam being completely independent of Zend_Service_Akismet since their individual futures are entirely unpredictable.
I think it is a good idea to implement a client for a few spam prevention providers out there. Nevertheless, more important would an implementation to chain such providers. It is a common use case to utilize more than one provider, including local measurements like simple blacklists or a naive bayesian filter or even multiple remote sources. Maybe this could be part of the Zend_Validate-package.
If it is possible to let the antispam clients share the same interface, the better it is. Create Zend_Service_AntiSpam_Client_Interface and let the TypePad and Akismet clients implement it. Deriving TypePad from Akismet is really not good idea, neither technically nor semantically.
ZF Home Page
Code Browser
Wiki Dashboard
I would not agree with the following assertion:
The first reason is more semantic.
Even if both services share the same API, it's wrong to assume that TypePad one is a subclass (or subproduct) of Akismet.
I would create an abstract antispam service instead.
The second reason is architectural. Even if TypePad antispam now shares the same Akismet implementation, it doesn't mean it will do the same in the future.
Akismet could add new features in the future not supported (for whatever reason) by TypePad and can drive to major problems.
Again, my proposal would be to use an abstract class.
My doubt is whether Akismet and Typepad should shipped as separated products or should be moved under a main Zend_Service_AntiSpam (Zend_Service_AntiSpam or Zend_Service_CommentAntiSpam or Zend_Service_AntiSpam_Comment? ...) "namespace".