Re: I made weblogger-el to support Windows Live blog API

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: I made weblogger-el to support Windows Live blog API

Mark A. Hershberger
[Ccing emacsweblogs]

Haojun Bao <[hidden email]> writes:

> First thanks for the great weblogger-el!

Your welcome.  I apologize for my late reply.

> I made some changes to weblogger.el and xml-rpc.el to make it support Windows
> Live blog, which is basically based on metaWeblog. Hope you find it
> useful.

Thank you.  Its because people like you test this out on different
platforms that I can continue to improve weblogger.el and xml-rpc.el.

>>> without these changes, the wrong APIs will be called, blogger.*
>>> instead of metaWeblog.*
>
>>> This patch is dirty, I think it will break blogger for
>>> metaWeblog. How can I make a better solution?

I note that the Windows Live weblogs have RSD headers that specify MetaWeblog.  The best way
would be to use RSD to determine what to do with a particular weblog.
Right now, it uses a MT-native call (mt.supportedMethods) to see what is
supported.  Obviously, if you implment MetaWeblog but mt, this will
fail.

Because of that, I'm not going to use the patch to weblogger.el.  But it
is clear that RSD should be my first priority for weblogger.el.

If you would like to try to tackle it (since I'm not sure when I will be
able to), I could help you out.

> -      (when mt_keywords
> - (cons "mt_keywords"   mt_keywords))
>>> This doesn't make sense, mt_keywords as a symbol is defined nowhere,
>>> and Elisp report error

Thanks for point this out.  Obviously I didn't test that.

> @@ -1456,9 +1454,9 @@
>     (cons "url"           (message-fetch-field "X-Url"))
>     (cons "title"     (or (message-fetch-field "Subject")
>   weblogger-default-title))
> -           (cons "categories" (vconcat (or (message-tokenize-header
> +           (cons "categories" (car (list (or (message-tokenize-header
>                                              (message-fetch-field "Keywords") ", ")
> -                                           weblogger-default-categories)))
> +                                           weblogger-default-categories))))
>
>>> From your latest xml-rpc, I guess you are trying to make xml-rpc
>>> array a real elisp vector here, right? but it's not working yet, so I
>>> made the above changes.
>
>>> "categories" parameter need to be an array of strings, and from
>>> xml-rpc comments, an array in xml-rpc is a list, not a vector in
>>> Elisp.

Ok, I'm going to assume this is working and I'll use your patch here.

> @@ -567,8 +567,13 @@
>            (result nil))
>        (while l
>          ;; iterate
> -        (setq elem (car l)
> -              l (cdr l))
> +        (cond
> +         ((listp l)
> +          (setq elem (car l)
> +                l (cdr l)))
> +         (t
> +          (setq elem l
> +                l nil)))
>
>>> Live Space will send xmlns attribute which is like (xmlns . "http://w3c/scheme")
>>> and it's not a list proper, so your old code will report error when
>>> (car "http://w3c/scheme")
>
>>> This fix is also dirty, because after this, what used to be (xmlns . "http://w3c/scheme")
>>> will change to (xmlns "http://w3c/scheme"), without the DOT in
>>> between. Hopefully it does not cause any harm.

Hrm… I'm not sure about this.  It'll take some testing.

> @@ -609,7 +614,7 @@
>                             url-http-response-status 200))
>                 (result (cond
>                          ;; A probable XML response
> -                        ((looking-at "<\\?xml ")
> +                        ((looking-at "\\(\357\273\277\\)?<\\?xml ")
>
>>> Live Space is ``dirty'', it will send a utf-8 head \357\273\277
>>> (0xfeff or sth. like that) before the <?xml.
>
>>> I wonder if these (attributes and utf-8 header) are allowed by the
>>> xml-rpc spec, since other clients like blogtk has no issue supporting
>>> Live Space

This is probably a short-coming of Emacs HTTP support and this isn't the
right place to fix the problem.

Thanks for your contributions and putting effort into tracking this
down!

Mark.


--
http://hexmode.com/

Embrace Ignorance.  Just don't get too attached.


_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs