Skip to content

Commit

Permalink
Merge pull request #18 from dspearson/master
Browse files Browse the repository at this point in the history
Minor spelling & grammar corrections.
  • Loading branch information
niwinz authored Sep 5, 2019
2 parents b70ebdb + d43e657 commit 98f879d
Showing 1 changed file with 18 additions and 18 deletions.
36 changes: 18 additions & 18 deletions doc/content.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ And the library works with the following platforms: *jdk7*, *jdk8*, *node-lts*.
== Getting started

The main goal of _octet_ is provide, multiplatform abstraction for work with
byte buffer's. Offering a ligweight api for define message types in a declarative
byte buffers. Offering a lightweight api for define message types in a declarative
way and use them for read or write to bytebuffers.

As previously said, _octet_ works with both most used clojure implementations:
Expand All @@ -59,7 +59,7 @@ Two most common composition types are: associative and indexed.

The difference of indexed and associative compositions is the input and output. In
associative composition the expected input and output is a map. And in indexed
composition, the expected input and input is a vector. Internally them represents
composition, the expected input and input is a vector. Internally it represents
the same value in bytes.

Let start defining one:
Expand Down Expand Up @@ -108,7 +108,7 @@ This operation is almost platform independent if the library defaults satisfies
(def buffer (buf/allocate 24))
----

The buffer allocation is parametrizable so you can specify the concrete
The buffer allocation is parameterisable so you can specify the concrete
implementation to use and the type of buffer:

.Example allocation 24 bytes size buffer with nio buffer implementation
Expand Down Expand Up @@ -136,7 +136,7 @@ You can see all supported options <<supported-bytebuffers,here>>

[NOTE]
====
The return value of `allocate` depens on implementation used. Is a plain instance
The return value of `allocate` depends on the implementation used. Is a plain instance
without additional wrapping. If you want access to its internals, you can do it
with native host platform api.
====
Expand All @@ -150,7 +150,7 @@ specs. Specs are simple schema on how the data should be read or write to the bu
.Example writing data into buffer using indexed composed schema
[source, clojure]
----
;; The indexed composed spec exptects a vector as input
;; The indexed composed spec expects a vector as input
(buf/write! buffer [22 true] my-spec1)
;; => 5
----
Expand Down Expand Up @@ -195,8 +195,8 @@ Also, you can perform the same operation, but using a associative spec:

[NOTE]
====
This works idependently of implementation used for allocate the buffer. Some
implementations has little limitations, es6 (cljs) as example, des not support
This works independently of implementation used for allocate the buffer. Some
implementations have a few limitations; es6 (cljs) as example, does not support
`int64` typespec due to platform limitations.
====

Expand Down Expand Up @@ -267,7 +267,7 @@ with `repeat` composition function:

=== Using arbitrary size type specs

Until now, we have seen examples alway using fixed size compositions. Fixed size
Until now, we have seen examples always using fixed size compositions. Fixed size
compositions are easy understand, the size of the spec can be know in any time.
But in some circumstances we want store arbitrary length. Strings are one great
example:
Expand Down Expand Up @@ -353,9 +353,9 @@ that it has always an overhead of 4 bytes for store the length of the vector.
=== Read and write spec to multiple byte buffers

In some circumstances (specially when we working with streams) the buffers are
splitted. The simplest but not very efficient approach will be copy all data in one
split. The simplest but not very efficient approach will be copy all data in one
unique byte buffer and read a spec from it. Octet comes with facilities for read a
spec from a vector of buffers that prevents unnecesary copy action.
spec from a vector of buffers that prevents unnecessary copy action.

.Example reading and writing data to a vector of buffers
[source, clojure]
Expand Down Expand Up @@ -386,7 +386,7 @@ situations. _octet_ is build around abstractions and define new type spec is not
very complicated job.

An typespec consists mainly in `ISpec` protocol that has two methods: `read` and
`write`. Let see an example defining a typespec for point of coordenades:
`write`. Let see an example defining a typespec for point of coordinades:

.Example definition of type spec that represents a point
[source, clojure]
Expand All @@ -401,7 +401,7 @@ An typespec consists mainly in `ISpec` protocol that has two methods: `read` and
(reify
spec/ISpecSize
(size [_]
;; we kwno that is datatype has fixed size in bytes
;; we know that is datatype has fixed size in bytes
;; that represents two int32.
8)
Expand Down Expand Up @@ -495,7 +495,7 @@ implements the same abstraction and can be used in read or write operations.
=== Byte order

All the builtin implementations uses the `:big-endian` as default byte order. That
value can be canched at any time using the provided `*byteorder*` dynamic var on
value can be cached at any time using the provided `*byteorder*` dynamic var on
the `octet.buffer` namespace.

Let see a little example:
Expand All @@ -514,7 +514,7 @@ Let see a little example:
;; => 19
(buf/read buffer myspec)
;; => BufferUnderflowException (because of incorect byte order)
;; => BufferUnderflowException (because of incorrect byte order)
(buf/with-byte-order :little-endian
(buf/read buffer myspec))
Expand All @@ -526,7 +526,7 @@ Let see a little example:

*What is the difference with _clojurewerkz/buffy_?*

*Buffy* is a excelent library, and I have used it in some circumstances, but is has
*Buffy* is a excellent library, and I have used it in some circumstances, but is has
some things that I personally don't like:

- It works only with netty bytebuf and I need an abstraction for work with
Expand All @@ -540,13 +540,13 @@ some things that I personally don't like:

*What is the difference with _ztellman/gloss_?*

Gloss is also similiar project, and has similar purposes, but it has several
differeces:
Gloss is also similar project, and has similar purposes, but it has several
differences:

- It has a limited set of types. Octet has an extensible abstraction for build own
arbitrary type specs.
- It only works with nio as buffer implementations. Octet exposes an extensible
abstraction and support few differents out of the box.
abstraction and supports a few different implementations out of the box.
- In my opinion it has slightly ugly and unclear api.
- Seems not very maintained (has issues from 2013).
- It not has support for ClojureScript.
Expand Down

0 comments on commit 98f879d

Please sign in to comment.