Simon Fell > Its just code > November 2005

Call me a neanderthal but I didn't run out and get an Xbox 360, you can probably count the number of times the existing Xbox has been turned on this year on your fingers. I did however pick up a copy of Need For Speed: Most Wanted Black Edition. (Which should win some award for gratuitously long title), which I've been really enjoying between all the turkey leftovers. Recommended if you like driving games.

I tried importing an RSS feed into google base, but it never got further than failing on the xml declration in my RSS feed, seems like they've still got a ways to go

4 years on, .NET starts to catch up with PocketSOAP :), .NET 2.0 supports automatically unzipping a gzipped response, and advertises this fact by including the Accept-Encoding: gzip header in the request, good so far. But the docs are wrong, the docs indicate that this is on by default, but my testing shows that its off by default and you need to explicitly turn it on (by doing svc.EnableDecompression = true; where svc is an instance of your WS proxy class). It a pity that they didn't also support compressing the request, looks like if you want that, you'll still need to go this route.

I also see that some of the Indigo WSDL parsing bugs seem to have been back ported to VS.NET 2005, opening the sforce WSDL in the VS.NET ide gives ~100 warnings, all bogus, it seems like

• the ide doesn't understand xsd:import correctly, it complains about undefined types, when in fact the type is declared in the imported schema.
• it suffers from the indigo bug around claiming that namespace declarations are missing when the NS decl is on the wsdl:definition element rather than in the schema itself (looks like it take the schema element out and makes it a new document without adding in all the in scope namespaces, tsch tsch, someone their should know better than that)

Just a reminder that the Salesforce.com data center move is this weekend.

I see that MS are continuing to punt on handling RFC 3023 correctly, basically they've been punting on it so long they can't implement it now because it would break to many things. Glad I'm not one of the unfortunate souls who's sat behind a transcoding proxy server that gets screwed by the tools not supporting this correctly.

A tech note with details of the upcoming changes and new features in the SForce Web Services API, you'll see that I spent the summer building yet another soap stack, I really liked how this one turned out.

Since the early days PocketSOAP has supported the xsd:long data type (a 64 bit signed integer) by mapping it to the VT_I8 variant type, however lots of people have run into the issue that most COM languages don't support the VT_I8 type (c++ being the only one I'm aware of that does). This is an issue for web services that use the xsd:long datatype, which is popular with the Java & C# folks, both of which support a native 64 bit integer type.

The just released PocketSOAP 1.5.3 adds a wrapper object to handle xsd:long better, this allows you to both send & receive xsd:long types.

You need to register the new type with the serializer factory so that it overrides the default mapping to the COM VT_I8 type. The object itself has properties for a stringified version, as well as access to the hi & lo dwords.

here's a sample usage

Dim e As New CoEnvelope
Dim xsdl As New CoXsdLong
xsdl.Register e.SerializerFactory
' a value of 4294967328
xsdl.LoDWord = 32
xsdl.HiDWord = 1
' or just do
xsdl.string = "4294967328"

e.setMethod "echoLong" , "http://unititests.pocketsoap.com/"
e.parameters.create "x", xsdl
http.send "http://some.where/", e
e.parse http

set xsdl = e.parameters.item(0).value
msgbox xsdl.string

Now that's a seriously good looking machine, drool indeed.

Now that's what I'm talking about