Tags: work

What browser?

On a Win 7 system, I'm already using Chrome and Firefox, but I need a third browser.  Don't ask, just accept that it streamlines my work flow - I just had this argument with my son, who assumes everyone should organize their work the way he does.
So - Iron has been a dismal failure, and I have an ingrained dislike of MS Explorer.  Anyone using anything else that they love?  Thanks for all suggestions.
fuck this i'll be a stripper

Web Services protocols

I'm getting in to app-to-app XMLey, Web Servicey stuff again at work.

This time, I'm on the other end of the conversation: someone's going to be creating a client that uses our application as a server, and I have to make the server bit, and document the API to the people writing the client.

So, the way I see it, I have three options:
  1. Straight XML POST
  2. XML-RPC
  3. SOAP
All of these have their upside and their downside:
  1. Using an XML POST/response with my own custom XML is delightfully lightweight. I don't have to fanny around with weirdo toolkits or anything, just syphon the data through XML::Simple and bip-bam-boom, Robert's yer father's brother. Simple ol' CGI script'll do the job, and it can even have a human-readable HTML form bolted on the front of it for testing and whatnot. The downside is that I'd have to churn out quite a decent chunk of documentation, including some kind of Schema or DTD or something for the XML.
  2. XML-RPC seems to be the middle ground. There are many supported toolkits for many environments for the client stuff (and for my stuff). The XML format is not that much more heavyweight than rolling my own, and it is at least well-standardized. The documentation effort should be more restricted to just describing the parameter and return types for the method(s) to be implemented
  3. SOAP is arguably the very definition of heavyweight. It's far and away the hardest to set up, but also the hardest to fuck up. On top of that, it's scalable in all sorts of directions should our needs change (and it seems like they might). The documentation effort should in theory be limited to building the WSDL file that documents the API in machine-readable format. For bonus points, it's thrillingly buzzword-friendly, and all corporations (ours included) like that sort of stuff
So, it's a mess, and I'm frankly a bit lost. Using a straight XML POST would definitely be the quickest to get set up and running on our end, documentation excluded. SOAP would be the most robust long-term solution, and would let us get all funkified and magical should the need arise. XML-RPC offers the best and worst of both worlds.

Oh, lazyweb, what do I do?