evolutional / flatbuffers-net Goto Github PK

Add support for the original_order attribute from the fbs schema. This forces the table serializer to handle fields in the order they were specified in and not size ordered.

When emitting a schema from a .NET type, we may wish to specify a user-defined name for a type or field. This can aid in resolving conflicts between similarly named types to provide a 'public' name for the fbs schema whilst being allowed to change the private code-side name.

The TextWriter used in the FlatBuffersSchemaWriter currently emits \r\n(CrLf) as the newline type. Provide the option for\n` (Lf) for better non-windows support.

Root issue #19

Create tests to verify that classes with inheritance will reflect and serialize/deserialize correctly.

Allow users to annotate their C# contracts with an attribute that dictates the field ordering. This performs the a similar role as the id attribute in the fbs schema

eg:

table Something {
   x:float (id: 1);
   y:float (id: 0);
}

Allow users to specify their own TypeModels without reflection; this is useful in situations where .NET reflection isn't available.

Allow a .NET struct/class to be serialized as a table/struct. The default behaviour will serialize a struct as a struct and a class as a table.

We will want per type overrides, so it makes sense for this to be an attribute.

Run a benchmark of the serializer/deserailizer routines to build a comparison of the performance between this library and the canonical flatc generated API

Create a rich set of documentation to detail the features of this project. Currently the README and unit tests are the only documentation. A goal would be to achieve either wiki-based documentation or a Github Pages portal with the various docs in it

Add support for an attribute to allow users to ignore fields on their types during reflection. This will allow fields to exist on a type that are skipped by any flatbuffers operations.

When writing the schema, we need to determine a map of dependencies and emit the fragments in the correct order. This will ensure that flatc can parse the schema correctly.

To quote the fbs schema doc:

key (on a field): this field is meant to be used as a key when sorting a vector of the type of table it sits in. Can be used for in-place binary search.

Not documented, but it is a fbs-built in attribute

Enums currently default to int as their underlying type, which means they will take 32-bits by default.

public MyEnum
{
    Etc,
}

The reflection routine should automatically determine the correct size based on the max value (in this case, 8 bits).

Add support for enum, vectors, struct and table as user fields

Currently we assume that all properties are both readable and writable. We may need to boil this up the the struct definition to say if the type can be serialized/deserialized

For example if all properties are writable, it can be deserialized, if all properties are readable it can be serialized. If some can't be read/write then the type cannot be serialized at all

Add default value support to the TypeModel.
Allow the user to specify the default value of a table field with an attribute.
Use the default value in the serialization process (eg: skip fields that equal default value when serializing, use default value to deserialize missing fields)

Create a specific set of FlatBuffersSchemaWriterException based exceptions for the schema generation process. This allows users to better diagnose and handle errors.

We need a way of providing namespace support. This would affect type name resolution during reflection and the writing of the fbs schema

There's currently a bug wherein a table that references another table will fail to serialize.

eg:

    public class Inner
    {
        public bool Prop { get; set;
    }

    public class Outer
    {
        public Inner TableProp { get; set; }
    }

It fails with a NotSupportedException during serialization, whether the field is null or not.

Increase testing over specific scenarios.

• Lists of structs
• Lists of tables
• Lists of enums
• Tables referencing shared objects (vectors, strings, etc)

etc

Whilst it's not possible to pick up comments from source, we can add a FlatBuffersCommentAttribute to allow users to annotate types (struct, table, union, enum) and fields. These comments would be written into the schema file.

Add support for user options in the schema writer.

• spaces or tabs
• indent size
• Java-style bracing

Whenever a table has a mix of reference types and value types, it will fail to serialize, reporting a NotSupportedException. This is due to a bug in the reference type serialization logic.

From the docs:

bit_flags (on an enum): the values of this field indicate bits, meaning that any value N specified in the schema will end up representing 1<<N, or if you don't specify values at all, you'll get the sequence 1, 2, 4, 8, ...

We need to handle this somehow. Ideally, it should be the [Flags] attribute, but doing so requires explicit setting of the enum values in .NET (eg: they're still sequential). Perhaps this is adequate and have a runtime check to verify?

Allow the specification of user attributes. This will predominantly support the emitting of them on the fbs schema files

From the fbs schema doc "force the alignment of this struct to be something higher than what it is naturally aligned to"

Support the root_type attribute from the fbs schema. Determine if it has an impact on the serializer, or primarily on the schema writer

Decide how we want to handle fbs attributes such as file_identifier and file_extension. We may wish to provide serialization functions to create buffer 'files'.

Investigate a strategy to serialize IEnumerable types. FlatBuffers currently requires knowledge of the vector item count up front for padding purposes.

It should be possible to modify the FlatBufferBuilder type in the base flatbuffers project to support writing of vectors without knowledge of the count until the end, however this would need to be pushed into the main google project first.

It may be possible to implement this functionality as an extension method, too.

Create a specific set of FlatBuffersSerializationException based exceptions for the serialization/deserialization process. This allows users to better diagnose and handle errors.

Add support for include in the schema writer. This will require some consideration on how schema fragments are packaged into modules and how modules interact.

Change Unit Test framework to NUnit to allow Travis builds to execute them

In the C++ version of google/flatbuffers there is the ability to verify the integrity of a buffer. This would be a useful utility to implement here.

Decide how union should be supported in the schema writer / serializer. In fbs this is essentially an enum which identifies the type of a blob of data in flatbuffer format.

Not a true stream serializer, as flatbuffers needs a full buffer - but we should add helpers to write the buffers to a Stream.

This would allow the quick creation of a buffer and dumping to a stream.

Ideally we should allow reading from a stream, but this may require some thought as FB isn't really a streamable format.

The library should be capable of reading the canonical 'Monster' test buffer. Create tests and objects to show this.

Currently field names are being serialized in the casing they're declared in .NET, we should serialize them as camelCase to match the fbs standard.

This likely should be an option (see #30)

Add support for emitting enum declarations from the FlatBuffersSchemaWriter.

TypeModels are currently created on the fly when a new type is discovered. There are situations where we don't want to allow this and should throw when this happens. This is applicable to scenarios where we want to handle our initialization in one place and not ad-hoc.

Json.Net has JsonConvert helpers which wrap the boilerplate serializer setup. It's useful for people wanting to quickly use the serializer with no config. We should add similar functionality.

The last field isn't being padded to align the struct, meaning that their inline size is incorrect.

Determine a strategy for serializing .NET Dictionary collections.

Provide support for the required attribute from the fbs schema. Throw exceptions when serializing a table which has no data for this field.

Root issue #19

Increase testing of structs/classes that use fields not properties. This includes the use of default values.

Circular dependencies between types aren't handled correctly in the schema handling process. The correct behaviour is to detect them and throw a user exception.

Create a specific set of FlatBuffersReflectionException based exceptions for the TypeModel reflection process. This allows users to better diagnose and handle errors.

Add support for "nested_flatbuffer".

Likely won't be applied to byte[] fields as per the fbs schema, but more likely a field of object type and the attribute will instruct how to serialize the type.

Add support for the deprecated fbs schema attribute. Determine if this should serialize data or not.

There are several BCL types in common use (eg: DateTime, TimeSpan, etc). Created a bcl.fbs schema for these types in a similar way that Marc Gravell did in Protobuf-net