T0rx in flight

OK, so these are some notes on things I've got on the go that need review/feedback.

Streaming

Branch is here: http://github.com/t0rx/Fudge-CSharp/commits/stream-test

This is a port of the Java streaming stuff Kirk did, but refactoring to extract interfaces for IFudgeStreamReader and IFudgeStreamWriter.

The cool bit is that once you do that you can implement many different encodings that people can use without needing to go via a FudgeMsg object. This opens up all kinds of possibilities as you could write serialisation code once that goes to XML, Fudge, Protocol buffers or whatever (yes, OK there are some niggly details but you get the idea). Serialising to a FudgeMsg object is also just another kind of encoding. There are a few things in the Encodings directory, and also a FudgeStreamPipe class which lets you just hook a writer up to a reader and let it do its stuff (e.g. hook a Fudge binary reader up to an XML writer and you've got a convertor).

I've now also added an extension method so that with any IFudgeStreamReader you can call .ReadToMsg() which just gives you a FudgeMsg.

Secondary types

This is in the master branch.

This came about when I was having some mad ideas around minimising things to indicators which we subsequently decided was too crazy. The secondary types are good though - this is a mechanism to support things like Guids which don't have a native Fudge representation so are translated in and out (e.g. to a byte[16]). The Guid example is in the SecondaryTypes() unit test in FudgeMsgTest, and the minimisation concept is also used to convert byte arrays to a fixed-width byte array type if appropriate in ByteArrayFieldType.

Secondary types need to be registered with the FudgeTypeDictionary so we should ship with things like Guids already in there (I've done this for .net Date types in the DateTime stuff below - have a look at the AddSecondaryTypes() method here).

DateTime encoding

Branch is here: http://github.com/t0rx/Fudge-CSharp/tree/FRN-15_DateTimeEncoding

What it says on the tin. FudgeDateTime class holds the data for the encoding described here, and FudgeDateTimeType does the binary reading/writing.

Conversion to and from native .net DateTime is supported with some handling of .net's idiosyncrasies, but it currently uses the .net DateTime for some operations which means it'll break if you put an extreme year in.

One of the issues is that to properly handle getting a value out of a FudgeMsg as a .net DateTime (using the secondary type stuff) it really needs something to tell it what behaviour to default to for the timezone - convert to UTC, convert to local time or leave as "unspecified" (these are the three options you have with a .net DateTime). This really should be a context property (see below), but would mean that the FudgeMsg would need to keep hold of the context (which it doesn't do currently).

Context properties

Branch is here: http://github.com/t0rx/Fudge-CSharp/tree/FRN-14_ContextProperties

DateTime handling as above is one example, but we're undoubtedly going to want more (e.g. specify lazy unpacking). I've implemented something which is extensible but fast (index-based array lookup to get the value from the context).

public class MyClass
{
    // Define our property that others can set in the context if they want
    public static readonly FudgeContextProperty MyProp = new FudgeContextProperty("SomeProperty", typeof(DateTimeKind));

    void Method(FudgeContext context)
    {
        var kind = (DateTimeKind)context.GetProperty(MyProp);
    }
}

Key classes are FudgeContextProperty and the changes to FudgeContext.

Serialisation

Branch is here: http://github.com/FudgeMsg/Fudge-CSharp/tree/serialization (it was done in the main repo before I forked off)

All the code is in the Serialization folder. This is before the streaming encoding was done and I've not looked at it since so it's quite out of date.

Key points:

• At the moment it relies on a SerializationTypeMap class to register names and types that will be used. Within the encoded stream, the type of an object (where needed) is just an integer, but the name is used for cross-language support.
• It handles graphs of objects including cycles.
• It supports both classes implementing an IFudgeSerializable interface, or going through a surrogate (this is needed for classes with no default constructor or where they may be cycles).
• I'd started to look at evolvability, but not taken it very far. Have a look at TrackingFudgeMsgTest.
• My intention was to add support for attribute-based control around serialisaton, default behaviour for just running through public properties, and also adding the ability to work with classes that have already been designed for .net serialisation or WCF.

So the question here is whether I should continue on this route, as I believe the Java and .net versions should be aligned for most of it but diverge for things that are really language-specific (e.g. .net serialisation support).