API Questions

I've run into a couple of issues in my development. Both are easy enough to work around but I'd prefer clarification if possible.

The first issue is with the response. I seem to be getting a garbage character at the beginning of my response stream. This is preventing me from duming the response directly into the XmlDocument.Load() method. To verify I wrote a console stub and dumped the stream to the screen and it shows as a " " there. I've worked around this by writing the stream to a string then checking for the first occurance of the "<" and passing the substring from there into the .LoadXml() method instead but it feels very hackish.

The second issue is with respect to the blogger.getUserInfo method call. According to the documentation I can find states that this method should return a struct yet the MSN implementation appears to return an array of structs. Given that you must pass in a userid and password how could there possibly be more than one user with the same id and password Am I looking at the wrong specs Again it's easy enough to work around but since I want to support both what the spec says (struct directly) and what MS does (stuct in array) it just extra work for no apparent reason... again it feels hackish.

Anyway thanks, I'm having a blast reinventing the wheel.



Answer this question

API Questions

  • mr kkh

    We are aware of both of these issues and they will be fixed shortly. Our dev was out on vacation but is back now. I'll be sure to announce when these bugs have been fixed.
  • Bob Tabor

    The debug version of my class throws an exception if it encounters a struct member it does not recognize (the release version just ignores them.) The exception contains the name and value of the unrecognized member. As of yesterday my getCategories method is throwing an exception claiming there is a title member in the categories struct. Looking at the xmlrpc spec this does not appear to be a valid member, nor does it seem to be a namespace extension. The value of this "title" member seems to be the same as the valid description member. The newly posted MSDN documentation also does not have a title member in the category struct. Am I missing something

    Thanks for resolving the BOM and UserInfo array issues, if taken out my workaround code and it's working great.


  • peterxz

    Kevin Daly wrote:

    If I might offer a suggestion, I think throwing an exception when you encounter an unexpected element in an XML-RPC response is probably a recipe for spending many happy hours with the debugger that you could just as easily be spending doing something else.
    In this case I personally favour the approach that HTML takes: handle what you expect to see, and ignore anything you don't.
    This is particularly true if you want to target more than one blog engine that uses the MetaWeblog API: there are subtle (and sometimes not so subtle) differences in what various implementations choose to include in a response, but if they're not relevant to your application, why worry about them

    As I mentioned in my original post only the DEBUG version of the class throws an exception and I've created my own exception class that contains the element and value information so this is very helpful to me. The release version of the class DOES ignore any unknown tags. I actually started by not throwing an exception and trying to implement just the standard. The problem is that there are so many extensions and optional elements (for example I believe it's valid for a post struct to optionally contain any of the elements of an rss 2.0 item) that I was spending a lot of time implementing things that MSN doesn't even support. Since what I'm developing is just a MSN Spaces bogging tool (not a generic one... at this time) I decided it would be better just to implement what MSN Spaces supported and leave the rest out (for later ) That's when I switched to the DEBUG throwing exceptions, each time I get an exception I handle that element and move on. I find this a far more efficient way of develping such a targeted tool.

    Just for clarification though I'd like to say that while I am limiting my support for optional elements to those that MSN Spaces currently supports. When I do implement them I try to do so in a generic way so that I don't have to go back and change it later should I decide to expand the tool. This is why I suggested a more generic way to get a permalink even though my tool is MSN specific anyway. So in summary I'm letting MSN Spaces determine WHAT I support, but I'd prefer not to allow them to determine HOW it is supported. The HOW I'd like to leave up to standards (though at this time that hasn't been possible in every case.)


  • betz

    It seems a number of weblog services provide this title element and some tools such as Blogjet depend on it to work correctly. It is a doc bug that this isn't mentioned in our documentation on MSDN.
  • fozia

    nhanson,

    The leading ("garbage") characters you see in MSN xml response is most likely the UTF byte order markup characters (normally takes the sequence of 0xEF 0xBB 0xBF). Dare has mentioned this will be fixed.

    (See http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=168204&SiteID=1)

     

     


  • Chandan Jhalani

     Dare Obasanjo - MSFT wrote:
    It seems a number of weblog services provide this title element and some tools such as Blogjet depend on it to work correctly. It is a doc bug that this isn't mentioned in our documentation on MSDN.

    Is there any standard that this title element comes from that I can reference I'm not talking about basic documentation like MSDN (which I'm sure it will eventually make it into) but an actual standard RFC or similar I've been using www.xmlrpc.com as a reference but this element is not defined there. MSDN does (and should) only document what MS supports which is informative but I'd also like to have a reference of what the overall standard supports and I can't find any standard/API (blogger API, metaWeblog API, Movable Type API, etc.) in which a title element is defined (optional or not) for the category struct.

    If just adding things without standards support is possible however I would like to suggest that on getPost and getRecentPosts the post struct that is return contain a published boolean indicating if the post is a draft or not. It would also be helpfull if the post struct contained a permalink string member. Right now I'm building the permalinks like this:

    url (from getUsersBlogs) + "/Blog/cns!" + postid + ".entry"

    But this is less than ideal because the two literals are MSN specific. It would be nice to be able to just use a fully contstructed permalink field from the post struct being returned from the server.


  • geertDCOD

    These bugs have been fixed.
  • MonkeyZa

    If I might offer a suggestion, I think throwing an exception when you encounter an unexpected element in an XML-RPC response is probably a recipe for spending many happy hours with the debugger that you could just as easily be spending doing something else.
    In this case I personally favour the approach that HTML takes: handle what you expect to see, and ignore anything you don't.
    This is particularly true if you want to target more than one blog engine that uses the MetaWeblog API: there are subtle (and sometimes not so subtle) differences in what various implementations choose to include in a response, but if they're not relevant to your application, why worry about them


  • API Questions