易栈网-膘叔（Neatstudio.COM）

易栈网-膘叔

mysql_pconnect的水挺深,apache下的数据库长连接

三步，临时解决新浪微博接口ID超长的BUG

转：用XML-RPC协议读写WordPress上的文章

RFC: MetaWeblog API

资料：WordPress的四种远程XML-RPC发布协议

mysql_pconnect的水挺深,apache下的数据库长连接

三步，临时解决新浪微博接口ID超长的BUG

转：用XML-RPC协议读写WordPress上的文章

RFC: MetaWeblog API

资料：WordPress的四种远程XML-RPC发布协议

日志分类

热门标签

日志归档

搜索文章

最新评论

博客信息

友情链接

浏览模式: 标准 | 列表分类:PHP

Submitted by gouki on 2011, September 9, 2:01 PM

PHP中的mysql_pconnect一直是大家所拿过来做比较的，但对于很多开发者来说，只知道一件事情，那就是mysql_pconnect是长连接，而mysql_connect是普通的连接。既然PHP没有所谓的连接池，那为什么又会有mysql_pconnect的功能呢？
本文是网上而来的，也是我难得看到一篇关于mysql_pconnect的文章。所以摘抄下来
原文来自：mysql_pconnect的水挺深,apache下的数据库长连接

　　php的mysql持久化连接,美好的目标,却拥有糟糕的口碑,往往令人敬而远之。这到底是为啥么。近距离观察后发现，这家伙也不容易啊，要看apache的脸色，还得听mysql指挥。

　　对于做为apache模块运行的php来说，要实现mysql持久化连接，首先得取决于apache这个web服务器是否支持Keep-Alive。

　　Keep-Alive是什么东西？它是http协议的一部分，让我们复习一下没有Keep-Alive的http请求，从客户在浏览器输入一个有效url地址开始，浏览器就会利用socket向url对应的web服务器发送一条tcp请求，这个请求成功一次就得需要来回握三次手才能确定，成功以后，浏览器利用socket tcp连接资源向web服务器请求http协议，发送以后就等着web服务器把http返回头和body发送回来，发回来后浏览器关闭socket连接，然后做http返回头和body的解析工作，最后呈现在浏览器上的就是漂亮的页面了。这里面有什么问题呢？tcp连接需要三次握手，也就是来回请求三次方能确定一个tcp请求是否成功，然后tcp关闭呢？来回需要4次请求才能完成!每次http请求就3次握手，4次拜拜，这来来回回的不嫌累啊，多少时间和资源都被浪费在socket连接关闭上了，能不能一次socket tcp连接发送多次http请求呢？于是Keep-Alive就应运而生,http/1.0里需要客户端自己在请求头加入 Connection:Keep-alive方能实现，在这里我们只考虑http1.1了，只需要设置一下apache，让它默认就是Keep- Alive持久连接模式(apache必须1.2+才能支持Keep-Alive).在httpd.conf里找到KeepAive配置项，果断设置为 On,MaxKeepAliveRequests果断为0(一个持久tcp最多允许的请求数，如果过小，很容易在tcp未过期的情况下，达到最大连接，那下次连接就又是新的tcp连接了,这里设置0表示不限制)，然后对于mysql_pconnect最重要的选项KeepAliveTimeout设置为 15(表示15秒).

　　好了，重启apache,测试一下，赶紧写行东西

PHP代码

<?php
echo "Apache进程号:".getmypid();
?>

很简单，获取当前php执行者(apache)的进程号，用浏览器浏览这个页面，看到什么？对,有看到一串进程号数字,15秒内,连续刷新页面,看看进程号有无变化?木有吧？现在把手拿开，交叉在胸前，度好时间，1秒，2秒，3,...15,16。好，过了15秒了，再去刷新页面,进程号有没有变化？变了！又是一个新的apache进程了，为什么15秒后就变成新的进程了?记得我们在apache里设置的KeepAliveTimeout吗？它的值就是15秒.现在我们应该大致清楚了,在web服务器默认打开KeepAlive的情况下，客户端第一次http成功请求后，apache不会立刻断开 socket,而是一直监听来自这一客户端的请求，监听多久?根据KeepAliveTimeout选项配置的时间决定，一旦超过这一时间,apache 就会断开socket了，那么下次同一客户端再次请求，apache就会新开一个进程来相应。所以我们之前15内不停的刷新页面，看到的进程号都是一致的，表明是浏览器请求给了同一个apache进程。

　　浏览器是怎么知道不需要tcp连接就可以直接发送http请求呢？因为http返回头里就会带上Connection:keep- alive,Keep-alive:15两行，意思就是让客户端浏览器明白，这次socket连接我这边还没关闭呢，你可以在15内继续使用这个连接，并发送http请求，于是乎浏览器就知道应该怎么做了.

　　那么，php的mysql连接资源是怎么被hold住的呢，这需要查看php的mysql_pconnect的函数代码，我看了下，大概的做法就是mysql_pconnect根据当前apache进程号，生成hash key,找hash表内有无对应的连接资源，没有则推入hash表，有则直接使用。有些代码片段可以说明(具体可查看php5.3.8源码 ext/mysql/php_mysql.c文件690行php_mysql_do_connect函数)

C++代码

#1.生成hash key
user=php_get_current_user();//获取当前php执行者(apache)的进程唯一标识号
hashed_details_length = spprintf(&hashed_details, 0, "mysql__%s_", user);//hashed_details就是hash key
#2.如果未找到已有资源，就推入hash表，名字叫persistent_list，如果找到就直接使用
/* try to find if we already have this link in our persistent list */
if (zend_hash_find(&EG(persistent_list), hashed_details, hashed_details_length+1, (void **) &le)==FAILURE) { /* we don't */
...
...
/* hash it up(推入hash表) */
Z_TYPE(new_le) = le_plink;
new_le.ptr = mysql;
if (zend_hash_update(&EG(persistent_list), hashed_details, hashed_details_length+1, (void *) &new_le, sizeof(zend_rsrc_list_entry), NULL)==FAILURE) {
...
...
}
}else{/* The link is in our list of persistent connections(连接已在hash表里)*/
...
...
mysql = (php_mysql_conn *) le->ptr;//直接使用对应的sql连接资源
...
...
}

zend_hash_find比较容易看明白,原型是zend_hash_find(hash表，key名,key长,value);如果找到，value就有值了。

　　说完Keep-Alive，该到mysql家串串门了，说的是mysql_pconnect，怎么能绕开mysql的设置。

　　影响mysql_pconnect最重要的两个参数就是wait_timeout和interactive_timeout,它们是什么东西？先撇一边，首先让我们把上面的代码改动一下php代码

PHP代码

<?php
$conn = mysql_pconnect("localhost","root","123456") or die("Can not connect to mysql");
echo "Mysql线程号:".mysql_thread_id($conn)."<br/>";
echo "Apache进程号".getmypid();
?>

以上的代码没啥好解释的，让我们用浏览器浏览这个页面，看到什么？看到两个显眼的数字。一个是mysql线程号，一个是apache进程号,好了，15秒后再刷新这个页面,发现这两个id都变了,因为已经是新的apache进程了,进程id是新的,hash key就变了,php只好重新连接mysql,连接资源推入persistent list。如果15内刷新呢？apache进程肯定不变，mysql线程号会变吗？答案得问mysql了。首先这个mysql_thread_id是什么东西？shell方式登录mysql后执行命令'show processlist;'，看到了什么？

mysql> show processlist;XML/HTML代码
+-----+------+-----------+------+---------+------+-------+------------------+  
| Id  | User | Host      | db   | Command | Time | State | Info             |  
+-----+------+-----------+------+---------+------+-------+------------------+  
| 348 | root | localhost | NULL | Query   |    0 | NULL  | show processlist |  
| 349 | root | localhost | NULL | Sleep   |    2 |       | NULL             |  
+-----+------+-----------+------+---------+------+-------+------------------+

,发现了很重要的信息，这个processlist列表就是记录了正在跑的线程，忽略Info列为show processlist那行,那行是你当前shell登录mysql的线程。php连接mysql的线程就是Id为349那行，如果读者自己做测试，应该知道这个Id=349在你的测试环境里是另外一个值，我们把这个值和网页里输出的mysql_thread_id($conn)做做比较，对！他们是一样的。接下来最重要的是观察Command列和Time列，Command = Sleep，表明什么？表明我们mysql_pconnect连接后就一直在sleep，Time字段就告诉我们，这个线程Sleep了多久,那么 Sleep了多久这个线程才能作废呢？那就是wait_timeout或者interactive_timeout要做的工作了,他们默认的值都是8小时,天啊,太久了,所以如果说web服务器关掉KeepAlive支持,那个这个processlist很容易就被撑爆,就爆出那个Too many connections的错误了,max_connectiosns配置得再多也没用。为了观察这两个参数,我们可以在mysql配置文件my.cnf里设置这两个值,找到[mysqld]节点，在里面设置多两行

配置代码
interactive_timeout = 60  
wait_timeout        = 30 配置完后，重启mysql,shell登录mysql,这时候show  processlist可以发现只有当前线程。然后运行那个带有mysql_pconnect的php页面,再回来mysql端show  processlist可发现，多了一个Commond为Sleep的线程,不停的show  processlist(方向键上+enter键)观察Time列的变化2,5,10..14!，突然那个Sleep线程程被kill掉了,咋回事,还没 到30秒呢,噢!忘了修改一下apache  keepalive的参数了,把KeepAliveTimeOut从15改成120(只为观察,才这么改),重启apache.刷新那个页面,好,开始不 停的show  processlist,2..5..10..14,15,..20...26....28,29!线程被kill,这次是因为wait_timeout 起了作用,浏览器那边停了30秒,30内如果浏览器刷新,那这个Time又会从0开始计时。这种连接不属于interactive  connection(mysql shell登录那种连接就属于interactive  connection)，所以采用了wait_timeout的值。如果mysql_pconnect的第4个参数改改呢

PHP代码

<?php
$conn = mysql_pconnect('localhost','root','123456',MYSQL_CLIENT_INTERACTIVE);
echo "Mysql线程号:".mysql_thread_id($conn)."<br/>";
echo "Apache进程号:".getmypid();
?>

刷新下页面,mysql那边开始刷show processlist，这回Time > 30也不会被kill，>60才被kill了,说明设置了MYSQL_CLIENT_INTERACTIVE,就会被mysql视为 interactive connection,那么这次php的mysql连接在60秒内未刷新的情况下,何时作废将取决于mysql的interactive_timeout 的配置值。

　　总结:php的mysql_pconnect要达到功效,首先必须保证apache是支持keep alive的,其次KeepAliveTimeOut应该设置多久呢,要根据自身站点的访问情况做调整,时间太短,keep alive没啥意义,时间太长,就很可能为一个闲客户端连接牺牲很多服务器资源,毕竟hold住socket监听进程是要消耗cpu内存的.最后 apache的KeepAliveTimeOut配置得和mysql的time out配置要有个平衡点,联系以上的观察,假设mysql_pconnect未带上第4个参数,如果apache的KeepAliveTimeOut设置的秒数比wait_timeout小,那真正对mysql_pconnect起作用的是apache而不是mysql的配置.这时如果mysql的 wait_timeout偏大,并发量大的情况下,很可能就一堆废弃的connection了,mysql这边如果不及时回收,那就很可能Too many connections了.可以如果KeepAliveTimeOut太大呢，又回到之前的问题，所以貌似Apache.KeepAliveTimeOu 比Mysql.wait_timeout 稍大，或者相等是比较好的方案,这样可以保证keep alive过期后,废弃的mysql连接可以及时被回收.

--------------

文章不算太长，看看即可，毕竟现在大多数项目都开始用PDO了，但这样深究的文章还是有值得学习的地方的

PHP | 评论:0 | 阅读:17860

Submitted by gouki on 2011, September 1, 8:51 AM

其实，不久前就知道新浪微博的ID的长度发生了变化，所以，原来的无符号长整形的长度是肯定不够了，超出后就变成了科学计数法。这样的URL可是没有办法在浏览器中打开的。
但服务器上一直没有这个问题，运行了uname -a后发现是64位系统，但测试机是32位的，怎么解决这个问题呢？
检查了一下oauth的代码，发现问题出在了json_decode函数上，因为取回来的数据都是字符串，只是在经过json_decode后，数字才超出长度了。知道这个问题后就好办了。
搜索json_decode，在这上面加上一行：
$response = preg_replace('@"id":(\d+)@','"id":"\\1"',$response);
为ID强制加上引号，变成字符串，而不是int型，所以在经过json_decode后，就仍然是字符串了。NND，新浪真偷懒，全部搞成字符串不就结了？到现在还在那里折腾整形不整形的。。

所幸，问题解决了。

PHP | 评论:0 | 阅读:15107

Submitted by gouki on 2011, August 31, 11:51 AM

这是一篇很小的例子，事实上网上这些例子是超多的，不过由于我是要模拟metaweblog或者是wordpress的一些操作，那我就必须要先了解很多相关的背景。
不过这里只是模拟一些发布和读取的接口，稍作了解即可。
原文来自：用XML-RPC协议读写WordPress上的文章我这里只简要的摘取一部分。

WordPress提供了XML-RPC接口使得第三方的博客写作软件(如windows live writer等)可以与之通信来发布和修改博客。我们也可以在网站上使用这个接口做一些工作，例如：在网站首页显示最新的博客、在博客之外的页面上发表博客文章、把博客与其他内容管理系统结合，等等。

一、开启XML-RPC支持

XML-RPC协议默认是未开启的，需要到WordPress管理后台的“设置–>撰写”里的“远程发布”给XML-RPC打上勾。其说明文字为：启用 WordPress，Movable Type，MetaWeblog和Blogger 的 XML-RPC发布协议。

二、获取接口的信息

我们查看博客首页的源代码，在head中可以发现类似这样的link项

XML/HTML代码

<link title="RSD" rel="EditURI" type="application/rsd+xml" href="http://blog.bluesky.cn/xmlrpc.php?rsd" />

其中的"RSD"是“Really Simple Discovery”的意思，也就是说这是一个“简单的发现博客编辑接口”的地址。我们用浏览器直接访问这个地址就可以在其返回XML中获知博客的 ID(blogID，一般这个的值是“1”)以及它所支持的接口类型和接口地址。

三、API接口选择

WordPress提供了对Blogger API、metaWeblog API、Movable Type API以及其自身的WordPress API的支持。其中WordPress API最为丰富，提供了包括操作评论文章在内的各种各样的支持。Blogger API功能较少，基本上淘汰不用了；而metaWeblog API提供了常用的接口且参数比较简洁，用得较多一些。

四、例子代码

以下是使用Incutio的XML-RPC库和Blogger API发布文章的例子，其中IXR库也是Wordpress自身所用的库，可以在“wp-includes/class-IXR.php”找到。

PHP代码

<?php
$xmlrpcurl='http://blog.bluesky.cn/xmlrpc.php';
$blogid='1';
$username='admin';
$password='pass';
$postTitle='标题';
$postContent='正文内容';
require('class-IXR.php'); // /wordpress/wp-includes/class-IXR.php
$client = new IXR_Client($xmlrpcurl);
$params=array(
'',
'blog_ID'=>$blogid,
'user_login'=>$username,
'user_pass'=>$password,
'post_content'=>'' . $postContent,
'publish'=>true
);
$params=array_values($params);
$client->query("blogger.newPost",$params);
$response=$client->getResponse();
if ($response['faultCode']==0){
print 'Success';
} else {
print 'Fail:' . $response['faultString'];
}
?>

以下是用XML-RPC for PHP库和metaWeblog接口发布文章的例子。要先下载phpxmlrpc库取出其中的xmlrpc.inc来用。

PHP代码

<?php
include("xmlrpc.inc"); // 这里要改成xmlrpc.inc所在的路径
$GLOBALS['xmlrpc_internalencoding'] = 'UTF-8';
define ('DOMAIN', 'blog.bluesky.cn'); // 博客的域名
define ('BLOGID', 1); // 博客ID，一般为1
define ('USER', 'admin'); // 博客登录的用户名
define ('PASSWORD', 'pass'); // 博客登录的密码
// 创建 xml-rpc client
$cl = new xmlrpc_client ( "/xmlrpc.php", DOMAIN, 80);
// 准备请求
$req = new xmlrpcmsg('metaWeblog.newPost');
// 逐个列出请求的参数:
$req->addParam ( new xmlrpcval ( BLOGID, 'int')); // 博客ID
$req->addParam ( new xmlrpcval ( USER, 'string' )); // 用户名
$req->addParam ( new xmlrpcval ( PASSWORD, 'string' )); // 密码
$struct = new xmlrpcval (
array (
"title" => new xmlrpcval ( '标题', 'string' ), // 标题
"description" => new xmlrpcval ( '正文内容', 'string'), // 内容
), "struct"
);
$req->addParam ( $struct );
$req->addParam ( new xmlrpcval (1, 'int')); // 立即发布
// 发送请求
$ans = $cl->send($req);
var_dump ( $ans );
?>

注意一定要加上：$GLOBALS['xmlrpc_internalencoding'] = ‘UTF-8′;这一句，否则不能正确处理中文。另一段也是用phpxmlrpc库和metaWeblog接口发表文章的例子代码，该代码使用了返回类型为“phpvals”，这样可以直接用返回结果的$r->val来获取文章ID号。

PHP代码

<?php
include("xmlrpc.inc");
$GLOBALS['xmlrpc_internalencoding'] = 'UTF-8';
$c = new xmlrpc_client("/xmlrpc.php", "blog.bluesky.cn", 80);
$content['title']="标题"; //标题
$content['description']="正文内容"; //内容
$content['mt_keywords']="标签1,标签2"; //标签
$content['wp_password']=""; //文章密码，输入后显示加密
$content['categories'] = array("分类1","分类2"); //分类名
$x = new xmlrpcmsg("metaWeblog.newPost",
array(php_xmlrpc_encode("1"), //BLOG ID
php_xmlrpc_encode("admin"), //用户名
php_xmlrpc_encode("pass"), //密码
php_xmlrpc_encode($content),
php_xmlrpc_encode("1"))); //立即发表
$c->return_type = 'phpvals';
$r =$c->send($x);
if ($r->errno=="0")
echo "发表成功，文章序号为：".$r->val;
else {
echo "出错了";
print_r($r);
}
?>

以下是读取最新一篇文章的例子代码：

PHP代码

<?php
include("xmlrpc.inc");
$GLOBALS['xmlrpc_internalencoding'] = 'UTF-8';
$c = new xmlrpc_client("/xmlrpc.php", "blog.bluesky.cn", 80);
$msg = new xmlrpcmsg('metaWeblog.getRecentPosts',
array(php_xmlrpc_encode("1"),
php_xmlrpc_encode("admin"),
php_xmlrpc_encode("pass"),
php_xmlrpc_encode("1")) );
$res = $c->send($msg);
$val = $res->value();
$val->arraymem(0)->structreset();
while (list($key, $v) = $val->arraymem(0)->structeach())
{
echo "Element: $key; Type: ".$v->kindOf()."; Value:".$v->scalarval()."\n";
}
?>

原文地址：http://blog.bluesky.cn/archives/466/using-xml-rpc-protocol-to-read-and-write-articles-on-wordpress.html

Tags: wordpress, xml-rpc, metaweblog

PHP | 评论:1 | 阅读:36886

Submitted by gouki on 2011, August 31, 11:32 AM

来自xmlrpc网站的资料：http://www.xmlrpc.com/metaWeblogApi
关于这些api还有一些背景资料在这里的：http://www.xmlrpc.com/stories/storyReader$2509，多看看啦。。。

Document status

This document was updated on 8/8/03, to incorporate all the RFCs related to the MetaWeblog API. The earlier version of the document is archived here. It has been reviewed by members of the MetaWeblog API mail list, and feedback has been incorporated.

On 8/24/03, I posted a last call for comments, and received several and incorporated some.

As of 8/26/03, this document is deployable. There may be changes, but they will be clearly documented, and will only clarify the spec, in no way will they change the format or protocol. It is now safe to deploy applications based on this spec.

What is the MetaWeblog API?

The MetaWeblog API (MWA) is a programming interface that allows external programs to get and set the text and attributes of weblog posts. It builds on the popular XML-RPC communication protocol, with implementations available in many popular programming environments.

Relationship between MetaWeblog API and the Blogger API

The MetaWeblog API is designed to enhance the Blogger API, which was limited in that it could only get and set the text of weblog posts. By the time MWA was introduced, in spring 2002, many weblog tools had more data stored with each post, and without an API that understood the extra data, content creation and editing tools could not access the data.

At the time of this writing, summer 2003, most popular weblog tools and editors support both the Blogger API and the MetaWeblog API.

Relationship between MetaWeblog API and RSS 2.0

The MetaWeblog API uses an XML-RPC struct to represent a weblog post. Rather than invent a new vocabulary for the metadata of a weblog post, we use the vocabulary for an item in RSS 2.0. So you can refer to a post's title, link and description; or its author, comments, enclosure, guid, etc using the already-familiar names given to those elements in RSS 2.0. Further since RSS 2.0 is extensible, so is the MetaWeblog API. We have designed conventions for representing attributes and namespaces in MWA.

Basic entry-points

There are three basic entry-points in the API:

metaWeblog.newPost (blogid, username, password, struct, publish) returns string

metaWeblog.editPost (postid, username, password, struct, publish) returns true

metaWeblog.getPost (postid, username, password) returns struct

The blogid, username, password and publish params are as in the Blogger API. newPost returns a string representation of the post id, again as defined by the Blogger API. The struct is where the juice is.

The struct

In newPost and editPost, content is not a string, as it is in the Blogger API, it's a struct. The defined members of struct are the elements of <item> in RSS 2.0, providing a rich variety of item-level metadata, with well-understood applications.

The three basic elements are title, link and description. For blogging tools that don't support titles and links, the description element holds what the Blogger API refers to as "content."

Where an element has attributes, for example, enclosure, pass a struct with sub-elements whose names match the names of the attributes according to the RSS 2.0 spec, url, length and type.

For the source element, pass a struct with sub-elements, url and name.

For categories, pass an array of strings of names of categories that the post belongs to, named categories. On the server side, it's not an error if the category doesn't exist, only record categories for ones that do exist.

In getPost, the returned value is a struct, as with the Blogger API, but it contains extra elements corresponding to the struct passed to newPost and editPost.

The server must ignore all elements that it doesn't understand.

In a call to metaWeblog.newPost or metaWeblog.editPost, if the struct contains a boolean named flNotOnHomePage, then the post does not appear on the home page, and only appears on the specified category pages.

Request and response

Here's an example of a request and a response.

Here's the post that this request is getting info about.

metaWeblog.newMediaObject

metaWeblog.newMediaObject (blogid, username, password, struct) returns struct

The blogid, username and password params are as in the Blogger API.

The struct must contain at least three elements, name, type and bits.

name is a string, it may be used to determine the name of the file that stores the object, or to display it in a list of objects. It determines how the weblog refers to the object. If the name is the same as an existing object stored in the weblog, it may replace the existing object.

type is a string, it indicates the type of the object, it's a standard MIME type, like audio/mpeg or image/jpeg or video/quicktime.

bits is a base64-encoded binary value containing the content of the object.

The struct may contain other elements, which may or may not be stored by the content management system.

If newMediaObject fails, it throws an error. If it succeeds, it returns a struct, which must contain at least one element, url, which is the url through which the object can be accessed. It must be either an FTP or HTTP url.

metaWeblog.getCategories

metaWeblog.getCategories (blogid, username, password) returns struct

The struct returned contains one struct for each category, containing the following elements: description, htmlUrl and rssUrl.

This entry-point allows editing tools to offer category-routing as a feature.

metaWeblog.getRecentPosts

metaWeblog.getRecentPosts (blogid, username, password, numberOfPosts) returns array of structs

Each struct represents a recent weblog post, containing the same information that a call to metaWeblog.getPost would return.

If numberOfPosts is 1, you get the most recent post. If it's 2 you also get the second most recent post, as the second array element. If numberOfPosts is greater than the number of posts in the weblog you get all the posts in the weblog.

Transmitting elements with attributes

The members of the struct passed in newPost and editPost come from the elements of items in RSS 2.0. The most commonly used core elements have no attributes, so it's clear how to include them in the struct. However, some elements, such as source, enclosure and category, may have attributes and a value. Here are a simple set of rules for elements that have attributes and a value. Note that these rules do not apply to enclosure and source, which are provided for specifically above.

1. If an element has attributes, then represent the element with a struct, and include the attributes as sub-elements of the struct.

2. If an element has both attributes and a value, make the element a struct, include the attributes as sub-elements, and create a sub-element for the value with the name _value. Note that this means that no element can be passed through the API that has an attribute whose name is _value.

Transmitting elements from namespaces

RSS 2.0 allows for the use of namespaces. If you wish to transmit an element that is part of a namespace include a sub-struct in the struct passed to newPost and editPost whose name is the URL that specifies the namespace. The sub-element(s) of the struct are the value(s) from the namespace that you wish to transmit.

Comments

The Blogger API provides a parameter called appkey that allows vendors to assign a key to developers so they can track and possibly limit usage of the API for certain tools. The MetaWeblog API doesn't specifically provide a parameter for an appkey. Applications that wish to transmit an appkey should add an element to the struct called appkey and set its value to the appkey that should be associated with the call.

Applications should use the fault-response scheme defined by XML-RPC. For example, trying to create, get, or edit a post without a valid username-password should generate a fault. Client applications should display the error string, as appropriate, to the user, for example, in a dialog, or in a server log.

Thanks

Thanks to Michael Bernstein for help editing this spec in summer 2003.

References

RSS 2.0; Dave Winer; 9/02.

RFC: MetaWeblog API; Dave Winer; 3/02.

Blogger API; Evan Williams; 8/01.

ManilaRPC; Andre Radke, Brent Simmons, Dave Winer; 1999.

XML-RPC; Dave Winer; 1998

Tags: wordpress, xml-rpc, metaweblog

PHP | 评论:0 | 阅读:21897

Submitted by gouki on 2011, August 31, 11:30 AM

没有什么好说的，学习一下这些资料。然后折腾中。
想用word发布博客，这些就必须要看。
原文来自：http://m2009.org/?p=998

WordPress支持四种远程发布协议，他们是 WordPress，Movable Type，MetaWeblog和Blogger 的 XML-RPC发布协议。

WordPress发布协议

WordPress 发布协议值wordpress自己的文章发布协议，他的接口最为丰富，提供了包括操作评论文章在内的各种各样的支持

WordPress发布协议文档：http://codex.wordpress.org/XML-RPC_wp

Movable Type发布协议

Movable Type，简称MT，是由位于美国加州的Six Apart公司推出的网志（blog）发布系统。它是全球最受欢迎的网志系统之一，包含多用户，评论，引用（TrackBack），主题等功能，并广泛的支持各种第三方插件。

Movable Type不仅可以应用于个人的网志系统，而且可以应用于商业、教育等领域。Movable Type于2007年12月12日正式宣布以GPLv2的协议开源。

Movable Type发布协议文档：http://www.movabletype.org/documentation/

Movable Type 文件集: http://mtbook.org/

MetaWeblog发布协议

The MetaWeblog API is an application programming interface created by software developer Dave Winer that enables weblog entries to be written, edited, and deleted using web services.

The API is implemented as an XML-RPC web service with three methods whose names describe their function: metaweblog.newPost(), metaweblog.getPost() and metaweblog.editPost(). These methods take arguments that specify the blog author’s username and password along with information related to an individual weblog entry.

The impetus for the creation of the API in 2002 was perceived limitations of the Blogger API, which serves the same purpose. Another weblog publishing API, the Atom Publishing Protocol became an IETF Internet standard (RFC 5023) in October 2007.

Many blog software applications and content mangement systems support the MetaWeblog API, as do numerous desktop clients.

MetaWeblog文档：http://www.xmlrpc.com/metaWeblogApi

Blogger发布协议

The Blogger Data API allows client applications to view and update Blogger content in the form of Google Data API feeds.

文档(墙外)：http://www.blogger.com/developers/api/1_docs/

google：http://code.google.com/intl/zh-CN/apis/blogger/

比较详细的api文档

API参考文档:http://www.sixapart.com/developers/xmlrpc/

Tags: wordpress, xml-rpc, metaweblog

PHP | 评论:0 | 阅读:23697

Records:647«‹46 47 48 49 505152 53 54 55 ›»

« 2025年02月 »