Thrift: OCaml TSocket fix
Summary: Now closes input channel on close. Also, transport exceptions are cleaner.
Reviewed by: mcslee
Test plan: Yes
Revert plan: yes
git-svn-id: https://svn.apache.org/repos/asf/incubator/thrift/trunk@665198 13f79535-47bb-0310-9956-ffa450edef68
diff --git a/lib/ocaml/README b/lib/ocaml/README
index 9f871fb..b304367 100644
--- a/lib/ocaml/README
+++ b/lib/ocaml/README
@@ -1,18 +1,34 @@
Library
-------
-The library abstract classes, exceptions, and general use functions are mostly jammed in Thrift.ml (an exception being TServer). Implementations live in their own files. I'm on the fence about whether it should be done with objects or modules/functors. Right now they are objects. TBinaryProtocol and TSocket are implemented. TServer and TSimpleServer classes are there, but the fastest route to a binary protocol socket server is to use TServer.run_basic_server which uses OCaml's own server abstraction. To that end, there is TChannelTransport which is a transport class parametrized on input and output channels that does nothing but wrap up the input and output functions.
+The library abstract classes, exceptions, and general use functions
+are mostly jammed in Thrift.ml (an exception being
+TServer).
-A note on making the library: Running make should create native and bytecode libraries.
+Generally, classes are used, however they are often put in their own
+module along with other relevant types and functions. The classes
+often called t, exceptions are called E.
+
+Implementations live in their own files. There is TBinaryProtocol,
+TSocket, TThreadedServer, TSimpleServer, and TServerSocket.
+
+A note on making the library: Running make should create native, debug
+code libraries, and a toplevel.
Struct format
-------------
-Structs are turned into classes. The fields are all option types and are initially None. Write is a method, but reading is done by a separate function (since there is no such thing as a static class). I'm still arguing with myself about whether structs should be put in their own modules along with this read function.
+Structs are turned into classes. The fields are all option types and
+are initially None. Write is a method, but reading is done by a
+separate function (since there is no such thing as a static
+class). The class type is t and is in a module with the name of the
+struct.
-enum format
+enum format
-----------
-Enums are put in their own module along with functions to_i and of_i which convert the ocaml types into ints. For example:
+Enums are put in their own module along with
+functions to_i and of_i which convert the ocaml types into ints. For
+example:
enum Numberz
{
@@ -26,7 +42,7 @@
==>
-module Numbers =
+module Numberz =
struct
type t =
| ONE
@@ -51,18 +67,29 @@
exception format
----------------
-Exceptions are kind of ugly since the exception structs can't be thrown directly. They also have this exception type which has the name BLAHBLAH_exn. For example, for an exception Xception you get:
+The same as structs except that the module also has an exception type
+E of t that is raised/caught.
-exception Xception_exn of xception
+For example, with an exception Xception,
+raise (Xception.E (new Xception.t))
+and
+try
+ ...
+with Xception.E e -> ...
list format
-----------
-Lists are turned into OCaml native lists
+Lists are turned into OCaml native lists.
Map/Set formats
---------------
-These are both turned into Hashtbl.t's.
+These are both turned into Hashtbl.t's. Set values are bool.
Services
--------
-The client is a class "client" parametrized on input and output protocols. The processor is a class parametrized on a handler. A handler is a class inheriting the iface abstract class. Unlike other implementations, client does not implement iface since iface functions must take option arguments so as to deal with the case where a client does not send all the arguments.
+The client is a class "client" parametrized on input and output
+protocols. The processor is a class parametrized on a handler. A
+handler is a class inheriting the iface abstract class. Unlike other
+implementations, client does not implement iface since iface functions
+must take option arguments so as to deal with the case where a client
+does not send all the arguments.