Consider a minimal build artifact for embedded runtimes

[bchavez]

Started off mostly for Unity3D, but also applies to those systems that don't have full threading await/async support like Windows Phone, IOT, and Xamarin that may prefer different threading / network stack architectures other than full desktop PC. Basically, the idea here is that the minimal build would only contain the AST for serialization and a BYOTNS interface (bring your own threading and network stack). Seems do-able with our current architecture (especially after #77 is implemented).

It would (and should) include basic primitives for response type conversion to help with JSON response conversion back into a native type that's usable by the embedded runtime.

As a general practice, we shouldn't encourage clients connecting directly to a publically exposed RethinkDB servers, but at the same time, it's not our call. We should not be the blocking issue if that's truly what the developer wants to do.

Other points,

• Consider packing this up for Unity Asset store, they prefer .cs files instead of dll
• Might need to abstract out the crypto functions, but need to double check this.
• http://jacksondunstan.com/articles/3206
• http://forum.unity3d.com/threads/free-trial-unity-c-6-0-compiler.314800/

• .NET 2.0 and .NET 3.0 are fully supported. (This is roughly C# 3.0)

• unity uses an old mono 2.6.x with .net 2.0/3.0 and a wee bit of 3.5. Linq is supported (but rarely used or understood by unity developers)

• No dynamic
• Lambdas are okay.

This would have to come after #77 and #33 (thrid-party serializer / deserializer), specifically in that order.

from slack:

@kamilion Okay, so after looking at the overall architecture of the driver.... here's what I can realistically provide in your situation with the C# driver... and without significantly increasing the #ifdef build complexity of the driver.
There are two fundamental functions of the C# driver:

1. Composing the ReQL query in C# in terms of the AST
2. The infrastructure to handle sending the query and processing the response
   https://github.com/bchavez/RethinkDb.Driver/wiki/Getting-Started#driver-architecture

Regarding No.1:
I can give you No.1 without much trouble. In fact we're pretty much already there, see: https://github.com/bchavez/RethinkDb.Driver/wiki/Extra-C%23-Driver-Features#serializing-reql-expressions we have the ability to serialize queries into strings. When I get around to #77 where I've fully separated AST and serialization processes this will yield a huge improvement to the overall driver architecture and allow us to do super great things. I just need time to finish it.

Regarding No.2 (SEND - RECV):
Query SEND:
So, the first problem we would run into (and most complex for the driver in your situation) is providing you with a way to send the query over a TCP socket given your current threading situation. Currently, the C# driver networking code is fully async all the way down to the network. This means you'll need async/await support beginning at any .Run(conn). And since you don't have async/await support, you would need to bring your own implementation on how to send and receive queries over the network. The driver is well architected enough (I think) to allow this (or wouldn't be much of a big pain to make it happen) to let you bring your own implementation.

Response RECV:
To process responses, I can probably provide you access to the converter primitives (which aren't async themselves, so I don't foresee any problem there.
What we could have is a minimal build that would give you RethinkDb.Driver.dll but without any of the async stuff and just leaves you with a way to provide your own request/response mechanism. I don't think we would have a NuGet package for it, but we could support a custom build task for supporting such scenarios.

This is just a preliminary review of what would be needed. You can make an official issue on your issue and I'll take a closer look at it. Unfortunately, I'm under contract at the moment, so these changes and custom build tasks would need to come after Issue 77 is done. But that's how we could move forward with resolving your issue.

🔮 🎎 _"Magic and technology. Voodoo dolls and chants. Electricity. Were makin weird science..."_