Simon Fell > Its just code > July 2006

We hit the Berkeley Kite Festival this afternoon, seemed way busier than last year, and the traffic trying to get out was dire, but it was a fun afternoon.

I took a ton of pictures of the Rokkaku kite battles, but none of them really give a good indication of what's going on, the drumming group (based in Emeryville i think) was really good.

And its always amazing to see Ray Bethell in action.

While I'm ranting and raving about WSDL, I should moan about this one again, this time its thanks to the Redmond folks for this one. Here's two wsdls they describe the same service, the messages on the wire, are Identiical, yet run them through wsdl.exe (or VS.NET's add web reference), and you'll see that the tools decide to change programming models on you, based on the wsdl:parts name attribute. This attribute is internal to the WSDL doc, and largely unused, yet VS.NET will switch between 2 different programming models based on the value in this attribute. I have no issues with a tool supporting multiple programming models, but why should I as a service author get to dictate to you what programming model to use, note that's this is the only way to affect the programming model generated, there's no swtich, wizard option or anything that i could find so that the client can indicate which programming model he'd like to us. It really makes no sense whatever. To compound the problem other vendors have copied this idoitic mistake, sheesh.

Paul Downey says the problem isn't so much that all databinding tools suck, it's that they all suck differently amen brother!. Hopefully the w3c databinding group will turn out something useful.

Why it is every WS vendor will tell you contract first is the only way to work, yet they all ship a Foo2WSDL tool, not only that, their intro to WS docs (found linked from the axis2 docs page) probably have you use it. I wonder why? oh, yeah, authoring WSDL by hand is practically impossible because its a peice of crap. One of you should have the fucking balls to stand by your Contract First blathering and ship a decent WSDL editor and not ship a Foo2WSDL cop-out. ohh, the irony I can smell it from here.

BTW, I agree that contract first is the best way to get interop, but I don't think the tool vendors really believe that they can make WS-* successful that way, YMMV

Sanjiva (of Axis / WSo2 fame) responds to my two ids post with a post called Salesforce Web service API is crappy .. so blame the tools, unfortuantly Sanjiva in this case doesn't know what he's talking about.

• This particular API that I was discussing (the Partner API) has no OO object model (to use Sanjiva's term), sure I never explicitly called out that i was talking about the partner API, but the clues are there. See for yourself, here's a copy of the WSDL I was talking about - partner.wsdl. (If you have a salesforce.com login, you can find this under setup -> integrate -> AppExchange API -> Partner WSDL).
• We do contract first, and the entire contents of the partner WSDL are authored by hand, not a single thing is generated from code (ok, actually the statusCode and exceptionCode enum's are generated from code, the rest is done by hand). I've never seen a tool that would be able to generate that WSDL from a bunch of classes.
• Did you even read the post, or just see the "tools are crap" and go on tilt ?
• I'll write a schema for that 2nd message and even put up a dummy endpoint that'll return it, but you get to try out a bunch of mainline WS tools and report your results.

Sanjiva goes on to say Note that if you had indeed done it right then there'd be no issue with changing tools for dealing with the contract. The contract is sacred and that's the only thing that matters- what my tool does is between me and my tool.. Well, the contract is sacred, and hasn't changed, yet I've burnt a lot of time trying to make sure that it's still usable with tools like Indigo and Axis2. What you really mean, is that the contract is sacred as long as I use the subset of XSD that the tools like (except that different tools like different subsets, and different vendors change their minds over what the right subset is).

BYW, last time i looked XSD has no object model, it has extensions & restictions, which some tools choose to map (with varying degree's of success) to their languages OO model, but that doesn't make XSD OO.

Finally, if you want to try out the Web Service's for yourself and see what all the fuss is about, go ahead and signup for a free developer account.

Update: Steve correctly points out that my tool rants are based on tool used as a caller of the salesforce.com API (where we have to worry about the gauntlet of mainstreeam and not so mainstream soap stacks, we are living the WS dream with clients using .NET, Java, Perl, Python, PHP, Ruby, Javascript and others to call our service), not rants about the tools we use internally to build the service.

This question comes up every now and then, someone takes a look at the response from the salesforce.com API query call and notices that Id is in there twice, its broke, come on, fix it already, damn on-demand slackers! e.g.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:partner.soap.sforce.com" xmlns:sf="urn:sobject.partner.soap.sforce.com">
<soapenv:Body>
 <queryResponse>
  <result xsi:type="QueryResult">
   <done>true</done>
   <queryLocator xsi:nil="true"/>
   <records xsi:type="sf:sObject">
    <sf:type>Contact</sf:type>
    <sf:Id>00330000004AAvsAAG</sf:Id>
    <sf:Id>00330000004AAvsAAG</sf:Id>
    <sf:LastName>Barr</sf:LastName> 
    <sf:FirstName>Tim</sf:FirstName>
    <sf:AccountId>00130000002g9wOAAQ</sf:AccountId>
   </records>
  <size>1</size>
</result></queryResponse></soapenv:Body></soapenv:Envelope>

Actually, what's going is is that the Id is suposed to be there twice, it makes more sense once you've looked at the WSDL, which defines sObject as

<complexType name="sObject">
  <sequence>
    <element name="type" type="xsd:string"/>
    <element name="fieldsToNull" type="xsd:string" nillable="true" minOccurs="0" maxOccurs="unbounded"/> 
    <element name="Id" type="tns:ID" nillable="true"/>
    <any namespace="##targetNamespace" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
  </sequence>
</complexType>

The first Id element is there to populate the explicit Id element in the sObject definition, the 2nd Id is there because you included it in the field list for your query (in this case the query was select id, firstname, lastname, accountId from contact where ....) We do this so that the any collection (the collection of elements that are mapped into the any element in the schema, and are typically exposed as an array of elements in the toolkits) contains exactly one element for every field you asked for in the query, and they're in the order you specified in your query, this makes it easier on the client to index into the array and grab the exact data they're expecting, without having to map the elements back to a dictionary to look them up by name. On the downside, if you're using a tool that's not driven by the WSDL, then this can cause all sorts of confusion. Its interesting (and annoying) to note how the tools and machinations of schema mean you end up distorting the messages you generate, If you were ignoring WSDL, Schema and the WS tools, the response would actually be something more like this.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="urn:partner.soap.sforce.com">
<soapenv:Body>
 <queryResult>
   <size>1</size>
   <done>true</done>
   <record>
    <type>Contact</type>
    <Id>00330000004AAvsAAG</Id>
    <LastName>Barr</LastName> 
    <FirstName>Tim</FirstName>
    <AccountId>00130000002g9wOAAQ</AccountId>
   </record>
</queryResult></soapenv:Body>

I think the thing that's really going to bug me down the road is the fact that each generation of tooling will want a different set of tweaks, and what works today for Axis 1.x and .NET 1.x isn't going to work for Axis 3.0 and Indigo II, will the tools ever save me, or just send me to the funny farm to drink coffee all day?

Back in March I talked about awstats, my main complaint was that I wanted a list of top downloads, Sean Carlos was kind enough to point me to his awstats extras page which amongst other useful tips, includes a note on how to get a top 10 downloads. I just setup it (painless enough), we'll find out in the morning when it has some new data to chew on how well it works, seems like it should do the trick nicely though, thanks Sean!

Following up on this & this, I got to the bottom of the SSL problems on Windows Mobile 5.0. The docs are delightfully short on details, all they say is call WSAIoctl with the SO_SSL_PERFORM_HANDSHAKE control code passing in the target server name. none of the docs I could find actually explain the details of how you pass this server name in, (neither do the CE 4.2 docs, when this server name passing was introduced), back when CE4.2 came out, i changed PocketHTTP to do

WSAIoctl( t->socket, SO_SSL_PERFORM_HANDSHAKE, (void *)(serverName), strlen(serverName), 0, 0, NULL, NULL, NULL ) 

This appeared to work, the call suceeded, the SSL connection gets established correctly, all is good and well. It turns out that on WM5.0, you need to pass in the length of the server name including the terminating NULL, either this is a change, or it seems more likely to me, the serverName stuff was added to the CE 4.2 docs, but was never implemented, now its implemented in WM5.0 it barfs. I never would of found the include the NULL in the length, its not mentioned in any MSDN docs I could fine, but I took a hint from this post on using the new SET_PEER_NAME option. So PocketHTTP, now does this

WSAIoctl( t->socket, SO_SSL_PERFORM_HANDSHAKE, (void *)(serverName), strlen(serverName)+1, 0, 0, NULL, NULL, NULL ) 

and all is well, this works fine on WM5.0, and despite all the signs that you need to use VS.NET 2005 to do WM5.0 builds, the latest PocketHTTP build is still done with eVC3, and it works fine on my WM5.0 device. PocketHTTP v.1.3.0 is out and has this fix in it.

The espresso lovers on Coffee Geek & Home Barista hold Caffe Fresco's Ambrosia blend in high regard (and rightly so), I figured I'd tried something new and got some of the Black Hand Blend, It quite unusual, rich, nutty and full of character the bag says, and that it is, its also quite spicy, it has a quite distinct peppery/cinnamon spicy kick to it, which I've never noticed in other blends, it works surprisingly well, I really like it. After all, I ordered some more, so it must be good :)

Some Espresso Temescal from Blue Bottle Coffee, yummy.

eVC3 (PocketPC, PocketPC2002) & eVC4 (PocketPC2003) were both free, but unless I'm miss reading this, to do WM5.0 dev work, you need to buy VS 2005 ? WTF

Update : Brad & I both figured the WM SDK would work with the free VS.NET Express C++ edition, but alas no cigar. Seems the cheapest way into WM 5.0 development is with the VS.NET Standard edition at $299. I guess the folks in Redmond figure they need to be making money from dev tools these days.

I hope the Redmond folks finally got around to shipping a usable SOAP stack, 'cause I doubt I'll shell out for it just to do PocketSOAP stuff on WM5.

Following on from my earlier SSlValidate problems, I found a blog post that details some of the SSL related changes for WM5.0. It looks like there's an extra WSAIoctl you need to do to have it pass the correct flag in dwFlags to your validation hook. It sucks that they "improved" this feature in such a backwards imcompatible way. (old code won't be making the additional call, so the hook will always get the wrong flags). But, hell, the screwed SSL on every previous release, why was I really expecting WM5.0 to be any better?

Indigo won't include a user agent for security reasons, but even new builds of IE continue to advertise every major MS framework you have installed on your machine, is a little consistency too much to ask for ?

Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.0;+MSDigitalLocker+Vista+1.3;+SLCC1;+.NET+CLR+2.0.50727;+Media+Center+PC+5.0;+WinFX+RunTime+3.0.50727;+PeoplePal+6.2;+MSOffice+12)

I've had numerous reports that the SSL support in PocketHTTP/SOAP always returns an error on Windows Mobile 5.0 devices, I've been digging through it and have tracked it down to what appears to be a bug in WM5.0. As per the docs I register a SslValidate hook, however the dwFlags parameter is always SSL_CERT_FLAG_ISSUER_UNKNOWN, regardless of the status of the root certificate. Previous versions of PocketPC (2003 & 2002) got this right. sigh.

I got my hands on a Windows Mobile 5 based PDA today, so far I'm completely underwhelmed, the first peice of software I installed decided it needed to reboot the device to finish the install (never seen this on older devices), so they've made WM5 better by making it more like XP :(. I fired up my eVB based test app, as expected it takes me to the web to install the eVB runtime (because golly, why on earth would you want the runtime for the development tools MSFT spent years telling you were the bee knees). However it seems the regular Microsoft.com URL shuffler has struck, and it takes you to a non existent page. First impressions are, wow, it really does suck as badly as the earlier incarnations. And everyone wonders why the crackberrys are insanely popular.

Got the category support up and running, the categories are listed in the rss and atom feeds, there's a per category home page (e.g. coffee, books) as well as per category atom feeds (e.g. coffee, web services, music). The category pages also advertise the per category feeds via auto discovery. I updated a bunch of posts (but not all) with their categories, and in the process found a couple of issues with non ascii text in pyRelaxer, so need to go look at that next.

Dare comments on a comment from Dave Winer talking about reach and inclusivity when building services. While in principle I agree that the more ways a given service can expose itself can give wider reach and make it more inclusive to different technologies, what I also see is that those multi protocol services tend to be cop outs. What I mean is that either the service is exposed through a primary protocol, and the other protocol offerings are simple wrappers (like the Live Expo services which has a laughably stupid soap api, all it does it transport the REST service results around as a string inside a soap envelope, why would you ever you this soap API, its not even like the code generators can do anything particularly useful with the WSDL. Another case of do as I say and not do as I do from MSFT). The other approach I've seen is that the services become limited by the lowest common demoninators of the protocol features, you can see this in Frontier/Radio where the SOAP stack doesn't really support anything more than the xml-rpc stack it has supports (even though SOAP does support a lot more). If you're going to expose your service through multiple protocols then I really think that should it should be done in such as way as to take full advantage of the features of each protocol.

Looks like the Art of Noise have a box set coming out soon, What Have You Done With My Body God? containg a bunch of unreleased tracks and other goodies, can't wait, I was disappointed they didn't do more after they got back together to do The Seduction of Claude Debussy, and I still kick myself every now and then that I missed them when they came to SF back in 99.

I've been working on a port of my RESTLog based blogging client to Python/wxWindows, the python libraries still seem to be a little rough around the edges, for example its trivial to convert to an iso8601 formated date, but there doesn't appear to be any easy way to get from an iso8601 formated date, back to an actual datetime instance. Still, compared to the Java (and some extent the original C# one i wrote) I seem to be able to spend less time on plumbing all the UI peices together and more time on actually writing code that does something useful. I added a clients tree to the RESTlog.NET project in sourceforge if anyone is interested. I'll hopefully get the C# client in there as well. I also plan to update both the server and client peices to support categories at some point soon.

I've been working my way through the Bolivia - 2005 Cup of Excellence - Agricabv Calama Marka that I got, there's just enough left to make one more cup of drip with it. It made a great cup of drip (using the melitta) fruity, very crisp and clean and stayed good as it cooled. I also french pressed it and put it through the mill with the vac-pot, they turned out good to, but surprising to me, not as good as the drip. If you drink a lot of drip be sure to try it out.

I couldn't resist the sale any longer, so ordered some of the Caffe Fresco Daterra Estate's Espresso Reserve, its the bargain of the summer at $10/Lb. I normally get the Ambrosia espresso blend as well when I order from Caffe Fresco, but this time thought I'd try something new, so settled on the Black Hand Blend, which has the intriguing description of Black Hand Blend Is Reminiscent Of The Hills Of Sicily. A Land Where Evening Breezes Are Charged With Fragrances From Citrus Trees. A Place Where Kitchens Are Filled With Aromas Of Wine And Tables Are Adorned With Nuts And Figs. Contents Of This Blend Are Secret - Reminiscent Of The Black Hand.. Sounds like it should be another one of Tony's masterpeices.

I headed out today to go get some beans, the original plan was to head to Ritual and pick up some hairbender, I waited and waited and waited some more, still no bus, so I headed to Blue Bottle instead. I got an awesome gibraltar at Blue Bottle, but alas the beans were a no show, they were out. The sun was out, So I walked over to Ritual and got my hairbender, had another gibraltar for good luck (also very yummy). Ritual was packed out, even with 6 or so folks working like mad behind the bar, the line was still to the door most of the time, I don't know how these guys manage to handle the insane number of drinks they make, and keep them all top notch. And that folks, concludes the San Francisco coffee tour, with the sad closure of Cafe Organica, the coffee tour is down to 2 stops, sad but true. (The gibraltar appears to be named after the glass its served in, so technically, the drink to the left which I made at home is not a gibraltar, because its not the right glass)