Simon Fell > Its just code > September 2004

Salesforce.com launched supportforce.com today.

Tim Bray "Does this mean we should worry that some of the ones above will be obsoleted? As in, when is it safe to start building?" This echo's my major concern with trying to build on the WS-* stack today, earlier specs have been superceded by completely different specs (RS-Routing anyone, WS-Attachments, SwA, DIME), for a number of specs there are competing vendor specs (WS-RM vs WS-Reliability). Recently we've seen revisions of WS-Addressing, WS-Eventing and other's with no real indication that we're not going to see more revisions, more new specs to supercede these. Basically the whole thing looks like a monstrously unstable stack of cards to me, and that's before you even start thinking about SOAP 1.2 & WSDL 2.0

Props to Dave, Mark and the rest of the Mindreef folks on landing Tim Ewald, should be quite an interesting outcome.

Russ says the next Bay Area Mobility Forum get together is this saturday, which makes 2 for 2 with scheduling clashes for me. Hopefully it'll be 3rd time luckly and i'll finally get to go to one of these.

So am i the only person who can't view my site in firefox pr1 ?, seems like its showing the gziped stream directly, rather than decoding it???. other sites that do gzip seem ok.

Update Brad was seeing it as well, I've turned off compression for now, until i can work out what's going on.

Congrats to the Mindreef folks on shipping SOAPScope 4.0, an amazing useful tool.

Just signed up for the xml devcon, I'm particularly interested in Rich Salz and Doug Purdy's sessions as these are things I'm spending a lot of time thinking about these days.

The sample purely uses the PocketSOAP engine, not any of the ASMX support, the next step would be to write a SoapExtension that used the PocketSOAP SwA engine, and then left the envelope processing to ASMX. Should be fairly straight forward I hope.

Prompted by an exchange on the PocketSOAP mailing list, I've just whipped together a web service written in c# and hosted in ASP.NET that uses the PocketSOAP attachments engine to get SwA support. I'm going to clean it up and a real sample out it when I get time, but for now it gives some ideas on how to hook things up for those people trying to get SwA support in ASP.NET

So I'm sure this is possible, I just can't work out the right set of incantations. I have a COM interface which represents a simple readable stream

[
	object,
	uuid(114BD3E3-983B-4509-8DD7-42DC36F4D262),
	local,
	helpstring("IStreamReader Interface"),
	pointer_default(unique)
]
interface IStreamReader : IUnknown
{
	HRESULT Read( void *pv,           // Pointer to buffer into which the stream is read
                      ULONG cb,           // Specifies the number of bytes to read
                      ULONG *pcbRead );   // Pointer to location that contains actual
                                          // number of bytes read

	HRESULT Reset() ;                 // resets the current position in the stream back to the begining.
} ;

No rocket science here, pass a buffer into the Read call and it'll populate some or all of it. Now, I'm trying to provide an implementation of this COM interface in C#, what I've got so far is

[ComImport, Guid("114BD3E3-983B-4509-8DD7-42DC36F4D262")]
[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IStreamReader
{
	[PreserveSig]
	void Read ( [MarshalAs(UnmanagedType.LPArray, SizeParamIndex=1)] byte [] buffer, 
			uint cb, 
			out uint pcbRead ) ;
	[PreserveSig]
	void Reset ();
}

Now I can see my call into the c# code, it gets a right sized buffer, it drops data into the buffer and updates pcbRead, everything looks fine on the .NET side, step through back to the C++ code, and pcbRead is fine, but there's no data in the buffer, it didn't get marshalled back. This seems to be because the buffer is only marshalled as an [in], I tried adding a ref to the byte [] buffer, but now when my c++ code tries to call it i get a HRESULT of 0x80131535 which is MarshalDirectiveException.

Anyone know the trick for this one ?

Update : As this things always go, I worked it out 5 minutes later, ditching the ref and adding an [In,Out] to the byte [] parameter did the trick.