Basic usage

The idea is very simple; you create a Fop2Client, add some event listeners, connect and authenticate and you're done.

var client = new Fop2Client();

//When connected OK try to authenticate
client.ConnectionStateChanged += (s, e) =>
{
    if (e.ConnectionState == ConnectionState.Connected)
        client.Authenticate("mycontext", "101", "mysecret");
    else
        Console.WriteLine("Connection failed");
};

//When we have an authenticationresult, show a message
client.AuthenticationResultReceived += (s, e) =>
{
    if (e.Result == AuthenticationStatus.Success)
        Console.WriteLine("Login OK!");
    else
        Console.WriteLine("Login failed!");
};

//Show messages as they are received
client.MessageReceived += (s, e) =>
{
    Console.WriteLine("Received: {0}", e.Message.Data);
};

//Let's kick everything into action!
client.Connect("192.168.1.123:4445");

The Fop2Client is a very low-level client; it allows you to directly control (within the Fop2 "protocol") the data being sent and handle the data being received as you please.

The "Fat" client

The Fop2 Fat Client extends the "normal" Fop2Client providing methods like Dial(), PickupRinging(), Record() etc. handling the internal details of each of these commands (the "fat" client, however, needs a lot of work). Both the normal and the "fat" client have extensive overloads and helper methods to make life easier. For example, there is a Send(string message) method that puts the 'raw' message on the wire and a Send(params string[] args) overload that handles concatenating all arguments:

client.Send("1|dial|00123456789|" + client.CurrentHash);
//equal to:
client.Send("1", "dial", "00123456789", client.CurrentHash);
//equal to:
fatclient.Dial("00123456789");

The "CurrentHash" property exposes the currently active hash that was acquired during authentication; this is required to be sent along to the server on some actions. Both clients (normal and "fat") keep track of this type of information; the idea is that the "fat" client only provides extra helper methods that keep the details away.

Currently we have chosen to extend the Fop2Client with a Fop2FatClient. Since there's a lot to be done, we might decide in the future to "wrap" the normal client in a "fat" client to hide some of the "normal" client's 'dirty' internal implementation details too. Also, the naming of "fat" client is likely to change to something like 'Fop2SmartClient' or similar; suggestions are welcome! We might even consider renaming the "normal" client to "Fop2BaseClient" and the "fat" client to "Fop2Client". Anything is possible at this time.

Messages sent and received

Messages sent to the server are just 'plain flat strings' (although the FatClient abstracts that away and even the Send(params string[] args) hides this a little. Messages received from the server always are of type Fop2Message. This class defines 4 properties: Button, Command, Data and Slot. These are the low-level properties received and parsed (and, where applicable, even deflated/base64-decoded etc. although we might have missed some messagetypes). The "fat" client will most likely be raising events that abstract these details away too such that a message like:

{ "btn": "1", "cmd": "foostatus", "data": "c3RhdHVzPW9rfGNvbG9yPXJlZHxiYXNlNjQ9c3Vja3M=", "slot": "" }

is raised as a FooStatus event (with corresponding FooStatusEventHandler, FooStatusEventArgs exposing the parsed properties from the base64-decoded data etc.).