Re: The RPCBlogging package

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? Cheers, -- Anant Find Freedom, Go Open Source! http://www.kix.in/