[Fudge|Acronym] is a hierarchical, typesafe, binary, self-describing message encoding system.
* *Hierarchical*: Fudge messages aren't just a flat structure, they can be nested, creating larger, more complex data structures.
* *Typesafe*: Individual fields in a Fudge message are provided with their type data encoded, so that you can extract data safely.
* *Binary*: Fudge encoded data is binary, making it much smaller than text-based representations like XML or JSON.
* *Self-Describing*: Fudge messages contain metadata about the fields encoded (like a name or an ordinal), meaning that you can manipulate them without knowing the schema in advance.
* *Message*: Fudge was originally designed for encoding data to pass in a Message Oriented Middleware system, and so are more suited to the types of objects likely to be transmitted over a network connection than to a pure streaming mode.
Fudge, however, *is _not_ a Message Oriented Middleware platform or standard.* While Fudge works well in MOM environments, it really focuses more on what goes in the body of the messages you send. Fudge works great with HTTP, JMS, and AMQP as the underlying network transport.
h2. Project Status
While Fudge is still in early days, it's presently being used in production by several applications.
* A binary [Encoding Specification] that defines how Fudge data is to be encoded;
* A [Java|Java Development] reference implementation;
* A [C#/.Net|CSharp Development] reference implementation;
* A [C|C Development] reference implementation; and
* A [Google Protocol Buffers|Fudge Proto] compatibility library.
You can track the precise status in our [Releases] page.
h2. Why Should I Use Fudge?
Fudge is primarily useful in situations where you have:
* Data exchanging between nodes in a distributed system; where
* You want to be able to do meaningful work with data without knowing at compile time the precise message format; and
* Performance and message size are important.
In a case where you have perfect control over all nodes, and can externally specify (though an API document or something similar) the schema for each type of message channel, you might be better off using something like [Google Protocol Buffers|http://code.google.com/apis/protocolbuffers/] or [Thrift|http://incubator.apache.org/thrift/].
h2. Project Details
* [License] : Fudge libraries are offered under the APLv2.
* [Copyright] : Currently, all copyright to Fudge libraries is held by [OpenGamma|http://www.opengamma.com/] Inc.
* [Sponsorship] : The Fudge Messaging project is sponsored by [OpenGamma|http://www.opengamma.com/].
h2. Getting Started
The easiest way to get started is to look at the [Encoding Specification], or the [Types] taxonomy, or the [Source Code]. Then, join the [Mailing List].
If you're looking to help us out, take a look at the [Ways To Help] page.
{section}
{column:width=60%}
{recently-updated}
{column}
{column:width=5%}
{column}
{column:width=35%}
h6. Navigate space
{pagetree}
{column}
{section}
* *Hierarchical*: Fudge messages aren't just a flat structure, they can be nested, creating larger, more complex data structures.
* *Typesafe*: Individual fields in a Fudge message are provided with their type data encoded, so that you can extract data safely.
* *Binary*: Fudge encoded data is binary, making it much smaller than text-based representations like XML or JSON.
* *Self-Describing*: Fudge messages contain metadata about the fields encoded (like a name or an ordinal), meaning that you can manipulate them without knowing the schema in advance.
* *Message*: Fudge was originally designed for encoding data to pass in a Message Oriented Middleware system, and so are more suited to the types of objects likely to be transmitted over a network connection than to a pure streaming mode.
Fudge, however, *is _not_ a Message Oriented Middleware platform or standard.* While Fudge works well in MOM environments, it really focuses more on what goes in the body of the messages you send. Fudge works great with HTTP, JMS, and AMQP as the underlying network transport.
h2. Project Status
While Fudge is still in early days, it's presently being used in production by several applications.
* A binary [Encoding Specification] that defines how Fudge data is to be encoded;
* A [Java|Java Development] reference implementation;
* A [C#/.Net|CSharp Development] reference implementation;
* A [C|C Development] reference implementation; and
* A [Google Protocol Buffers|Fudge Proto] compatibility library.
You can track the precise status in our [Releases] page.
h2. Why Should I Use Fudge?
Fudge is primarily useful in situations where you have:
* Data exchanging between nodes in a distributed system; where
* You want to be able to do meaningful work with data without knowing at compile time the precise message format; and
* Performance and message size are important.
In a case where you have perfect control over all nodes, and can externally specify (though an API document or something similar) the schema for each type of message channel, you might be better off using something like [Google Protocol Buffers|http://code.google.com/apis/protocolbuffers/] or [Thrift|http://incubator.apache.org/thrift/].
h2. Project Details
* [License] : Fudge libraries are offered under the APLv2.
* [Copyright] : Currently, all copyright to Fudge libraries is held by [OpenGamma|http://www.opengamma.com/] Inc.
* [Sponsorship] : The Fudge Messaging project is sponsored by [OpenGamma|http://www.opengamma.com/].
h2. Getting Started
The easiest way to get started is to look at the [Encoding Specification], or the [Types] taxonomy, or the [Source Code]. Then, join the [Mailing List].
If you're looking to help us out, take a look at the [Ways To Help] page.
{section}
{column:width=60%}
{recently-updated}
{column}
{column:width=5%}
{column}
{column:width=35%}
h6. Navigate space
{pagetree}
{column}
{section}