Generating Silverlight / Windows Phone compatible Thrift proxies

Thrift is a software framework for scalable cross-language services development. It combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml. http://thrift.apache.org/

There are two reasons for this post:

• to float some ideas for C# changes to the Thrift development community.
• to remind myself in the future what I need to do to download, modify and build the Windows Thrift compiler, and

The idea is to maintain backwards compatibility, whilst at the same time generating Silverlight (and consequently Windows Phone 7) compatible proxies.

There are two sets of changes.  One to the C# code generator (t_cpp_generator.cpp), and the other to the runtime files (mainly THttpClient.cs).

Downloading and building the thrift compiler

To try out these changes on Windows, first install the latest version of Cygwin from http://cygwin.com/, then install the various packages as described here: http://wiki.apache.org/thrift/ThriftInstallationWin32

You’ll also need to install Subversion.

Next pop open the Cygwin shell, and fetch the latest source, as described here: http://thrift.apache.org/download/

Finally, build the source you downloaded, again as described here:

http://wiki.apache.org/thrift/ThriftInstallationWin32

In my environment I build using:

And then I run the new thrift compiler:

Code Generator changes

The code generator (t_cpp_generator.cpp) changes involve generating two additional methods for each “standard” method: a Begin_… method and an End_… method.

Whereas previously there might just have been a method such as this:

SyncState getSyncState(string authenticationToken);

Now, two additional methods get generated:

#if SILVERLIGHT
    IAsyncResult Begin_getSyncState(AsyncCallback callback, object state, string authenticationToken);
    SyncState End_getSyncState(IAsyncResult asyncResult);
#endif

The two methods allow for the asynchronous invocation of methods, using the standard .NET asynchronous invocation pattern.

In addition, the generated standard method (“getSyncState”) method is modified when building for Silverlight, to make use of the Begin… and End… methods:

    public SyncState getSyncState(string authenticationToken)
    {
    #if !SILVERLIGHT
        send_getSyncState(authenticationToken);
        return recv_getSyncState();
     
    #else
        var asyncResult = Begin_getSyncState(null, null, authenticationToken);
        return End_getSyncState(asyncResult);
    
   #endif
   }

As you can see, when not running Silverlight the standard code path is invoked, but when running Silverlight the asynchronous methods are invoked (the End… method blocks the current thread until the Begin… method completes).  This is not something you should be doing on the UI thread.

The generated Begin… and End… methods are pretty thin:

  public IAsyncResult Begin_getSyncState(AsyncCallback callback, object state, string authenticationToken)
    {
        return send_getSyncState(callback, state, authenticationToken);
    }
     
    public SyncState End_getSyncState(IAsyncResult asyncResult)
    {
        oprot_.Transport.EndFlush(asyncResult);
        return recv_getSyncState();
   }

Note the call to EndFlush above – this is one of the changes made to the runtime.  The other is invoked by the generated send_getSyncState method:

    #if SILVERLIGHT
    public IAsyncResult send_getSyncState(AsyncCallback callback, object state, string authenticationToken)
    #else
    public void send_getSyncState(string authenticationToken)
    #endif
    {
        oprot_.WriteMessageBegin(new TMessage("getSyncState", TMessageType.Call, seqid_));
        getSyncState_args args = new getSyncState_args();
        args.AuthenticationToken = authenticationToken;
       args.Write(oprot_);
       oprot_.WriteMessageEnd();
   #if SILVERLIGHT
       return oprot_.Transport.BeginFlush(callback, state);
   #else
       oprot_.Transport.Flush();
    #endif
    }

The generated recv_getSyncState() has not changed.

The changes in the generated code boil down to asynchronous invocations at the transport layer (BeginFlush and EndFlush).

There are also changes to #ifdef out the Serializable attribute for generated structs, since this is not supported by Silverlight.

Runtime changes

There are minor tweaks required to THashSet, TProtocol and TBinaryProtocol because Silverlight does not support the full .NET framework API.

The main change is to TTransport.cs to introduce the BeginFlush and EndFlush methods shown above, and then to THttpClient.cs to actually implement these methods.

The existing Flush method is #ifdefed out when building using Silverlight, because it makes synchronous calls which are not supported by Silverlight.

Instead, the BeginFlush builds a request and then invokes the HttpWebRequest.BeginGetRequestStream method, passing a local GetRequestStreamCallback method as the callback.

The GetRequestStreamCallback method is invoked once the runtime has the request stream.  It then writes out the data and invokes the HttpWebRequest.BeginGetResponse method, passing a local GetResponseCallback method as callback.

The GetResponseCallback notifies the original caller (in the generated code) that the request has now completed.

The EndFlush method waits for the corresponding BeginFlush method to complete, and if there was an exception thrown at any point, it raises the corresponding exception.

The changes

The changes files are here.  If there is interest and these changes make sense, I’ll submit a patch.