1 files changed, 3 insertions, 3 deletions

diff --git a/docs/Nails.html b/docs/Nails.html
index 1f99f4d..4eca750 100644
--- a/docs/Nails.html
+++ b/docs/Nails.html
@@ -17,7 +17,7 @@
 <p>It's entirely up to the web server how it actually stores the objects. I would recommend just storing the commands that define an object, but there will be things like IARs with XML files, exports from other viewers, and such around. Storing just the commands means that they can just be dumped direct to the command pump. XML would have to be translated first. On the other hand, inventories store non object assets, like textures, sound samples, scripts, etc. These could be stored in their native formats.</p>
 <p>&nbsp;</p>
 <h2> sim data store </h2>
-<p>Stores objects and their data that are in the sim. Again, it's a web server, but completely public. Though just like ordinary web servers, parts could be private to members only. Most of what was said about inventory data stores applies. There is a change of emphasis though, these would be public in general, with privacy an option, where inventory is private in general, with public being an option. Note that objects and other assets that are contents of a sim object should not be public by default, perhaps they could be handled by inventory data stores. Inventory data stores could be very simple data stores, with authorization, so would be perfect to be used as data stores for objects contents. Lets us reuse code and protocols, and can share code on the same server.</p>
+<p>Stores objects and their data that are in the sim. Again, it's a web server, but completely public. Though just like ordinary web servers, parts could be private to members only. Most of what was said about inventory data stores applies. There is a change of emphasis though, these would be public in general, with privacy an option, where inventory is private in general, with public being an option. Note that objects and other assets that are contents of a sim object should not be public by default, perhaps they could be handled by inventory data stores. Inventory data stores could be very simple data stores, with authorisation, so would be perfect to be used as data stores for objects contents. Lets us reuse code and protocols, and can share code on the same server.</p>
 <p>A sim data store could be a web proxy in front of any user in that sim. This is for any inventory data store an the users own computer, so that they can hide behind that sims proxy. Perhaps this could be another module? Not sure how to handle inventory transfers to offline users, especially those without some other web server to have an inventory data store on. Likely users will be a member of at least one web site somewhere that offers inventory data stores.</p>
 <p>&nbsp;</p>
 <h2> physics engine </h2>
@@ -38,7 +38,7 @@
 <p>So basically, it manages FIFO queues of commands, one per client. Filtering out any command type the client requests, filtering for objects of interest, or filtering object data on a frame rate basis per object. Every now and then, it has to sync the sim data store as well, so that the sim state is persistent across restarts, and clients can just download complete objects from the store when they first need them. Phew.</p>
 <p>A good optimisation would be for the sim data store and command pump to be the same module. The pump has to keep the current state of objects in memory anyway, and knows how to pump the command data out, all it needs is a persistent backing store to write to and read at start up.</p>
 <p>As an optional wrapper around the command pump, could be translators for those that want REST, JSON, XMLRPC, or other bloat. With commands to switch to and from these and the native binary protocol. Native binary protocol must always be supported, and always be the default until requested otherwise. 99.9999% of Internet traffic does not NEED to be human readable on the wire, human readable is not so easy for computers to read, they need to translate it. Why slow everyone down? I will insist that these protocol translators operate outside the command pump, don't want to slow that down to satisfy peoples longing for bloat. They should be separate processes, preferably operating on separate cores, or even entirely different computers. They will naturally talk the tight binary protocol to the command pump, just like every one else.</p>
-<p>There are three basic internet protocols we could use as the basis for the wire traffic. TCP, UDP, and SCTP. SCTP would be a great candidate, except for the lack of MacOS support. I think we should try SCTP, with TCP as backup, SCTP support might come to Mac sooner or later.</p>
+<p>There are three basic Internet protocols we could use as the basis for the wire traffic. TCP, UDP, and SCTP. SCTP would be a great candidate, except for the lack of MacOS support. I think we should try SCTP, with TCP as backup, SCTP support might come to Mac sooner or later.</p>
 <p>&nbsp;</p>
 <h2> command channels and language </h2>
 <p>In other parts of this document, a command channel is mentioned. Most of the data flowing through this command channel would be for setting or changing prim parameters. I propose a binary format based on llSetLinkPrimitiveParams() <a href="http://lslwiki.net/lslwiki/wakka.php?wakka=llSetLinkPrimitiveParams&amp;show_comments=1#comments">http://lslwiki.net/lslwiki/wakka.php?wakka=llSetLinkPrimitiveParams&amp;show_comments=1#comments</a></p>
@@ -176,7 +176,7 @@
 <h2> Windlight commands. </h2>
 <p>&nbsp;</p>
 <h2> Avatar commands. </h2>
-<p>Some of this could be dealt with by treating the avatar as a prim. In fact, Alices proposed animation system deals with animating avatars and prims the same way.</p>
+<p>Some of this could be dealt with by treating the avatar as a prim. In fact, Alice's proposed animation system deals with animating avatars and prims the same way.</p>
 <p>&nbsp;</p>
 <h2> Animation commands. </h2>
 <p>Alice is working on that over at the <a href="BVJ.html">BVJ</a> page.</p>