Re: The RPCBlogging package

On 3/19/06, Anant Narayanan <anant@kix.in> wrote: > Hi Ian, > > > The main point here is that the only thing really provided by the > > RPCBlogger base class is the factory method and some constants. There's > > no reason to have those in the driver classes, so I suggest that you > > split them out one way or another. > > Yes, I see your point. But the RPCBlogger class also contains prototypes > for two basic functions of any blogging system; which are likely to be > implemented by all API's. That is why the class is present in the first > place, it's primary objective is to provide the "no-frills" base for all > drivers. > > Separating the two classes would be fine, but that's repetition of code. > The base classes are abstract and so we can't merge all possible methods > into one class; since that will force drivers to implement methods that > they don't even support. > > > Is there any reason why you couldn't make this abstract enough to work > > with both methods? > > Interesting idea. Some implications though: Both methods use different > protocols. And that would make this single package dependent on two PEAR > packages instead of only one now: XML_RPC and XML_Atom; when someone may > not even use the drivers require XML_Atom or vice versa. > > Won't it be better if we have two separate packages, each dependent one > only one more package that it requires? > It could be optionally dependant on both of them. It would make more sense to have a Blogging package IMHO which just connects in different ways. -- Justin Patrin