that into an XML-RPC call hurts my head.That's because
API doesn't specify how to deal with required attributes. Or
with namespaces. Or with nested XML elements... Of
couse, one could one by one address these items, and in the
process reinvent XML.
For reference, here again is a
post for this item. Now here it is
RPC, with the troublesome attribute included as a
comment. Finally, here a hypotheticalSOAP
version, with the
API defined control parameters passed as a SOAP header.
IMHO, if one can find
a way to work with transfer level authentication and authorization,
one should. If application level control information is
required, then an
header mechanism may be appropriate. And this need not
totally be an either/or situation. One can use transfer level
authentication and authorization with SOAP. Ideally, the
blogid would not be a parameter, but would be included in the
URI. Things like that.
And, again, the offer is open: if consensus were reached around
a weblog post API which either wrapped or subsetted (or both) RSS
2.0, I would work with others to provide the validator.
Update: The XML RPC example has been updated based on
the instructions in the MetaWeblog API specification.
Sam, what do you mean? I'm at work on RSSLibJ (http://rsslibj.sourceforge.net) which will have a version ready for release soon - so RSS direction is important for me. But RSS is output, for RSSLibJ, so I'm not sure how it dovetails with what you're talking about.
Sam and Matt, the MetaWeblog API spec does indeed tell you what to do with attributes, in fact it uses an example exactly the case that Matt says it offers no guidance on. And even if it didn't there's no cause to rip up the pavement and build a new road. We'll just add detail to the spec. I started a new page on the XML-RPC site. So let's figure out what to do, if you want to do that. If you want to reinvent the wheel, you can do that too.
Can we step back a bit and work out a problem scope and domain? If there's not a solution needed (i.e., one exists that fulfills the need, or the problem isn't a problem) that's fine - but since I'm working on a syndication library at the moment, it's a good time to address the flaws of the protocol, as well as addressing data transfer.
Thanks for clarifying. I feel like a moron for not seeing it before. I've spent quite a bit of time skimming and referring to that page, and somehow I missed it. After skipping right past it, I headed over to the RSS specs for the source element. Then I tried to figure out how to cram that back into an XML-RPC call. I think that's what hurt my head.
Hey Matt, no problem, happens all the time. To Sam, no to both your questions. Radio still supports the Blogger API and recommend to others that they do so as well. In fact the MetaWeblog API is not a complete API without the Blogger API. Anyway, when you use all caps it sounds like you're yelling. If so, why? I don't get it. Anyway, I put up an RFC that addresses this stuff on the XML-RPC website.
Dave - I suggested that weblogging tools consider supporting RESTLog in addition to other API's. You asked "why rip up the pavement", so I restated what I was suggesting with emphasis on two words: added, and additional.
I'll take a look at the RFC and let you know if I have any questions.
Sam Ruby: Matt Croydon: Translating that into an XML-RPC call hurts my head. That's because the MetaWeblog API doesn't specify how to deal with required attributes. Or with namespaces. Or with nested XML elements... Of couse, one c...
David Johnson in response to Sam Ruby's post about weblog APIs: It hurts my head too. I'd rather see a SOAP interface where everything is specified by WSDL, or a RESTLog-like interface where everything is drop-dead simple. I'd love to see a...
RSS based APIs. Matt Croydon: Translating that into an XML-RPC call hurts my head. That's because the MetaWeblog API doesn't specify how to deal with required attributes. Or with namespaces. Or with nested XML elements... Of couse,...
In another thread to my O'Reilly post on Weblogs, Web services and the future, an anonymous poster raises the notion of using SOAP instead of XML-RPC. While other disagree I think this notion definite has merit as part of a solution when combined...