The RPCBlogging package

Hello All,

I just proposed the Services_RPCBlogging package and invite
comments on
it. Some notes:

1) The package is named RPCBlogging because it implements
only the
XML-RPC protocol for blog management. This will
differentiate it from
the later (better?) protocol: the Atom API, a package for
which is also
in the pipeline.

2) The package follows a driver style, and the package
includes drivers
for the Blogger and metaWeblog RPC API's. Drivers for other
RPC based
API's such as Livejornal or MoveableType maybe added later.

3) An example that illustrates the packages use by
connecting to a
blogger.com blog and publishing a post is included.

4) The package is intended for use by both web and desktop
(PHP-Gtk)
applications that will deal with blogs.

Again, comments are greatly appreciated!

Best Regards,
-- 
Anant

Find Freedom, Go Open Source!
http://www.kix.in/

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

On Mar 18, 2006, at 11:36 AM, Anant Narayanan wrote:

> Hello All,
>
> I just proposed the Services_RPCBlogging package and
invite  
> comments on
> it. Some notes:
>
Sorry for replying here, but I left my PEAR login on another
system.

- You're using PHP 5, but RPCBlogging_Post is littered with
get/set  
methods. You should use PHP 5's __get() and __set()

- You seem to have driver-specific code in RPCBlogging_Post;
switch  
(RPCBlogging::$driver) in __construct(). The Post class
should be  
naïve, and this should be handled by the drivers.

- This check - if (!($content instanceof RPCBlogging_Post) -
can be  
replaced with a type hint in the function prototype. I see
it in the  
metaWebLog driver; if it's present in the other drivers, it
could be  
fixed there as well.

- Is there any reason you're using the XML_RPC PEAR package
instead  
of PHP 5's native XML-RPC extension?

- You need to get your directory structure in line with PEAR
 
standards. Services/RPCBlogging/RPCBlogging_Blogger.php
should be  
something more like:
Services/RPCBlogging/Driver/Blogger.php.

- RPCBlogger::factory() needs work. It should also be naïve,
and just  
try to load a class/file generated from the driver you ask
for. With  
your if/else setup, you'll have to modify it every time you
add a  
driver. It should be something like:

public static function &factory($driver, $options =
array())
{
     $class = 'RPCBlogger_Driver_' . $driver . '.php';
     $file = 'RPCBlogger/Driver/' . $driver . '.php';
     incluide_once $file;
     if (!is_class($file)) {
         throw new Execption('Driver not found: ' .
$driver);
     }
     $inst = new $driver($options);
     return $inst;
}

- You should move the functions needed by the drivers out of
 
RPCBlogger and into RPCBlogger_Extended; RPCBlogger_Extended
 
shouldn't extend RPCBlogger. Extended could be renamed to  
RPCBlogger_Driver, and form the base class for the other
drivers,  
since that's basically what it already does.

- Class names need to have the name of the package, i.e.  
Services_RPCBlogger_Extended.

- I'm not sold on the name. Perhaps Services_Blog ?
-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi Ian,

First of all, thanks for your valuable comments.

> - Is there any reason you're using the XML_RPC PEAR
package instead of
> PHP 5's native XML-RPC extension?

I see "Warnings" all over the place in the PHP
manual about the in-built
XML-RPC functions. It's also not very versatile and also
poorly
documented. The PEAR package on the other hand, is well
documented and
mature. It seems to suit our purpose well, and most of all,
it works
just as expected (not the case with the inbuilt functions).

> - You should move the functions needed by the drivers
out of RPCBlogger
> and into RPCBlogger_Extended; RPCBlogger_Extended
shouldn't extend
> RPCBlogger. Extended could be renamed to
RPCBlogger_Driver, and form the
> base class for the other drivers, since that's
basically what it already
> does.

RPCBlogger_Extended cannot be the base class for all drivers
because
some API's (like the Blogger API) doesn't support all
those extra
methods. What I've tried to achieve here, is keeping all
methods that
are SURE to be present in ALL API's in RPCBlogger and keep
the extra
ones in RPCBlogger_Extended. Some drivers will extend from
RPCBlogger,
and more feature-rich ones from RPCBlogger_Extended.

> - I'm not sold on the name. Perhaps Services_Blog ?

Probably yes; but as I mentioned before, I would like to
bring in RPC
somewhere in the name because it's not the only way you
could deal with
blogs. There is a newer method that uses HTTP requests: the
Atom API.
This is another great way of communicating with blogs (A
package for
which is also on the way, maybe after I finish with this
one).

Is Services_RPCBlog Ok? (Consequentially, we could name the
other
package Services_AtomBlog).

I have taken all your other points into account and hope to
act on them
in the coming week.

Thank you for your time.

Best Regards,
-- 
Anant

Find Freedom, Go Open Source!
http://www.kix.in/

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

On 3/19/06, Anant Narayanan <anantkix.in> wrote:
> Hi Ian,
>
> First of all, thanks for your valuable comments.
>
> > - Is there any reason you're using the XML_RPC
PEAR package instead of
> > PHP 5's native XML-RPC extension?
>
> I see "Warnings" all over the place in the
PHP manual about the in-built
> XML-RPC functions. It's also not very versatile and
also poorly
> documented. The PEAR package on the other hand, is well
documented and
> mature. It seems to suit our purpose well, and most of
all, it works
> just as expected (not the case with the inbuilt
functions).
>
> > - You should move the functions needed by the
drivers out of RPCBlogger
> > and into RPCBlogger_Extended; RPCBlogger_Extended
shouldn't extend
> > RPCBlogger. Extended could be renamed to
RPCBlogger_Driver, and form the
> > base class for the other drivers, since that's
basically what it already
> > does.
>
> RPCBlogger_Extended cannot be the base class for all
drivers because
> some API's (like the Blogger API) doesn't support all
those extra
> methods. What I've tried to achieve here, is keeping
all methods that
> are SURE to be present in ALL API's in RPCBlogger and
keep the extra
> ones in RPCBlogger_Extended. Some drivers will extend
from RPCBlogger,
> and more feature-rich ones from RPCBlogger_Extended.
>
> > - I'm not sold on the name. Perhaps Services_Blog
?
>
> Probably yes; but as I mentioned before, I would like
to bring in RPC
> somewhere in the name because it's not the only way
you could deal with
> blogs. There is a newer method that uses HTTP requests:
the Atom API.
> This is another great way of communicating with blogs
(A package for
> which is also on the way, maybe after I finish with
this one).
>
> Is Services_RPCBlog Ok? (Consequentially, we could name
the other
> package Services_AtomBlog).
>


I would suggest Services_Blog_RPC and Services_Blog_Atom. In
addition,
couldn't RPC and Atom just be two drivers to one
Services_Blog
package?

--
Justin Patrin

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