Stand back, I need to vent.
xmlStorageSystem is Bad and Wrong. Or at least, Radio's implementation of it is. I'm not talking any high-falutin' grandioseness like REST vs XML-RPC, or even the fact that the whole "updating files on a webserver via HTTP" thing is done quite a lot better by WebDAV. I'm just looking at the specification itself (and trying to implement the bloody thing) and getting more and more annoyed.
This is the tip of the iceberg:
- ping and getServerCapabilities are always called together by the client. This is pointless redundancy. It would be better if ping returned information that is constantly updated, while getServerCapabilities sends information that either seldomly updates, or only needs to be re-checked in response to client events.
- Some methods try to do too much. The user info struct that Radio sends with every ping is an example. A user's name, email address or blog name change rarely, it'd be far better off to farm that function out to an updateUserinfo verb.
- Some methods return a great deal of irrelevant or redundant information. Pretty much every command tells you what the URL of your blog is, even though that's never going to change. The ping command returns the userinfo you sent in your request, and even tells you what your own client's user-agent is. getServerCapabilities tells you what the URL is for the XML-RPC interface of the server, even though you'd have to have already called that URL to access the method in the first place.
- The protocol is mis-named. The protocol has outgrown its function of being a way to maintain files on an HTTP server, it's the server-side implementation of Radio. This is made obvious by the amount of radio-specific information that the methods return. Perhaps the radioCommunityServer namespace should have all the Radio-specific stuff, which would simplify xmlStorageSystem no end.
I'm tempted to write a specification for a replacement, but the simple fact is that xmlStorageSystem is not really a specification, it's "Whatever Radio Does", and Userland are far too busy with other things to correct an old kludge, especially one that is probably intertwingled with a hell of a lot of code in Radio/RCS/Frontier by now.
4:32:02 PM 
|
|
