The RPCBlogging package

On 3/19/06, Anant Narayanan <anantkix.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

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php