This time it's an attachment.
Sorry about the mangling before.
Laura Dean wrote:
>
> Hi. I noticed some typos and such when reading the framework
> documentation on the web. So, here are the fixes I would make
> to the following files:
>
> src/xdocs/framework/designing-a-component.xml
> src/xdocs/framework/lifecycle.xml
> src/xdocs/framework/security.xml
> src/xdocs/framework/what-is-a-composer.xml
? diff.txt
Index: src/xdocs/framework/designing-a-component.xml
===================================================================
RCS file:
/home/cvspublic/jakarta-avalon/src/xdocs/framework/designing-a-component.xml,v
retrieving revision 1.4
diff -u -r1.4 designing-a-component.xml
--- src/xdocs/framework/designing-a-component.xml 31 Jan 2002 15:43:52 -0000
1.4
+++ src/xdocs/framework/designing-a-component.xml 13 Feb 2002 16:35:56 -0000
@@ -26,7 +26,7 @@
<p>
All Components are an integral part of Avalon, so there is really
nothing to be done beyond specifying its interface (role). It is
- important to identify and document it's social contract with the
+ important to identify and document its social contract with the
rest of the system. What I mean by social contract is the order
of dependencies, what it needs to function, and what it supplies
to the rest of the system.
@@ -46,7 +46,7 @@
as generic as possible and still accurately represent its role.
</p>
<p>
- Because the contexts that may not be an integral part of Avalon,
+ Because the contexts may not be an integral part of Avalon,
you must take care to use the Component in the same manner as
Avalon would. That means that you follow the order of concerns
that Avalon has specified for those concerns.
Index: src/xdocs/framework/lifecycle.xml
===================================================================
RCS file: /home/cvspublic/jakarta-avalon/src/xdocs/framework/lifecycle.xml,v
retrieving revision 1.4
diff -u -r1.4 lifecycle.xml
--- src/xdocs/framework/lifecycle.xml 31 Jan 2002 15:43:52 -0000 1.4
+++ src/xdocs/framework/lifecycle.xml 13 Feb 2002 16:35:56 -0000
@@ -85,7 +85,7 @@
<li>configure</li>
<li>finalize</li>
</ol>
- <p>The lifecycle of a <code>Component</code> implementing only Composer will
be:</p>
+ <p>The lifecycle of a <code>Component</code> implementing only Composable
+will be:</p>
<ol>
<li>constructor</li>
<li>compose</li>
Index: src/xdocs/framework/security.xml
===================================================================
RCS file: /home/cvspublic/jakarta-avalon/src/xdocs/framework/security.xml,v
retrieving revision 1.6
diff -u -r1.6 security.xml
--- src/xdocs/framework/security.xml 31 Jan 2002 15:43:52 -0000 1.6
+++ src/xdocs/framework/security.xml 13 Feb 2002 16:35:56 -0000
@@ -17,8 +17,8 @@
In this context security is defined as protection of data, and
quality of service (QOS). Both of these fall under security because
a system must protect itself from these two forms of attack. When
- a company loses a system, they lose business, and the money the
- lose are scary amounts.
+ a company loses a system, they lose business, and the money they
+ lose can reach scary amounts.
</p>
<p>
For the purpose of this discussion, we will address the first
@@ -40,9 +40,9 @@
is the correct one.
</p>
<p>
- There are two sides of authentication. There is the side that you
- are authenticating an entity you want to do business with. Then there
- is the side of an entity wanting to do business with you. This is
+ There are two sides of authentication. On one side, you are
+ authenticating an entity you want to do business with. On the other
+ side, there is an entity wanting to do business with you. This is
best understood when you bring it into a financial realm. Let's say
you want to get a loan from XYZ bank. If you initiate the exchange
at their facility, you have already authenticated them--although you
@@ -101,7 +101,7 @@
<ol>
<li>
Never expose anything that does not need to be exposed. Information
- hiding is as much an important part of security as it is in Component
+ hiding is as important in security as it is in Component
Oriented Programming (COP).
</li>
<li>
@@ -110,7 +110,7 @@
</li>
<li>
Any Component that originates from another source, and especially over
- a wire should be treated with suspicion. Authenticate it, and if it
+ a wire, should be treated with suspicion. Authenticate it, and if it
checks out, trust it. Otherwise, don't give it access--you don't know
where it's been or who created it.
</li>
@@ -120,23 +120,23 @@
</ol>
</s2>
</s1>
- <s1 title="From the Sublime to the Rediculous">
+ <s1 title="From the Sublime to the Ridiculous">
<p>
Throughout my short career I have been exposed to a wide range of security
implementations. Having worked for a DoD contractor, I learned about physical
security requirements (how to manage paper files, and the rules and
regulations
regarding secure information). However in a recent attempt to install a
- solution at our customer's site, I learned the most about computer security
+ solution at our customer's site, I learned more about computer security
than I have at any other time.
</p>
<p>
- Our customer, being a well known corporation whom I will call ACME for
- anonymity is in custody of sensitive information. Product movement data,
+ Our customer, a well known corporation whom I will call ACME for
+ anonymity, is in custody of sensitive information. Product movement data,
financial data, and demographic data are all stored in one of a couple
huge server farms. Our application was to reside in the De-Militarize
Zone (DMZ), and talk to a database behind the firewall. When they discovered
that the application server we chose required Remote Procedure Calls (the
- result of many CERT advisories in the Unix world) we hit a brick wall. Our
+ subject of many CERT advisories in the Unix world), we hit a brick wall. Our
application was no longer trusted, and was not to be installed. Luckily
the next version of the application server fixed that problem.
</p>
@@ -144,45 +144,46 @@
In the midst of this, I decided to learn as much as I could about operating
in a hardened environment. Hardening involves turning off access to anything
that is not needed, and only allowing what is needed. All mail servers, ftp
- servers, rpc services, telnet, or any other clear text communications port
needs
- to be removed. All communications into and out of the box needs to be
+ servers, rpc services, telnet, and any other clear text communications ports
+need
+ to be removed. All communication into and out of the box needs to be
encrypted, with the exception of HTTP (although we were using HTTPS).
</p>
<p>
All of this was necessary. I understand the principles behind it. However,
I decided to ask their security analyst how to learn more--so we don't run
into this problem again. He gave me a link to
- <link href="http://www.sans.org";>SANS institute</link> and a word of advice,
"Be
- paranoid. Don't trust anything."
+ <link href="http://www.sans.org";>SANS institute</link> and a word of
+ advice: "Be paranoid. Don't trust anything."
</p>
<p>
There is a point where the aforementioned philosophy goes a bit too far. The
- case and point relates to a story I heard working with the DoD. During the
+ case in point relates to a story I heard working with the DoD. During the
height of the "Cold War" between the US and Russia, a US commanding
officer required that all the computers be placed on these huge power
conditioners to reduce the Electro-Magnetic Interference (EMI) coming from the
power line feedback of the computers. His rationalization was that he was
positive KGB agents had the technology that they could read the EMI
interference
on the power lines and read the bits on the computers. In hind sight this is
- improbable, no one can identify the bits travelling on a computer from EMI in
the
+ improbable; no one can identify the bits travelling on a computer from EMI in
+the
power lines due to the level of noise (clocks, addressing lines,
<em>encrypted data</em>, and other computers on the network).
</p>
<p>
The security industry have a general rule of thumb to ensure that you don't
spend
- too much time in this area. It should be more costly to crack the server than
+ too much time in this area: The cost of cracking the server should
+ be more than
the information that is protected is worth. Basically it boils down to this:
sites like Slashdot and SourceForge do not require as much security as a Bank.
Protecting free information is not as critical as protecting peoples bank
accounts.
- I am not minimizing the contributions of the afformentioned sites to the world
+ I am not minimizing the contributions of the aforementioned sites to the world
as a whole, but people become much more agitated if their bank account is wiped
clean than if their news article is defaced. This is not to say that if you
are
- protecting free information that you can safely ignore security. While the
information
+ protecting free information then you can safely ignore security. While the
+information
is monetarily free to customers, it has value that can be measured in pride,
respect,
and accountability.
</p>
<p>
- The morale of the story is be paranoid to a point. Avalon is designed to be
+ The moral of the story is be paranoid to a point. Avalon is designed to be
a trusted system, and will be improved to work in an untrusted network.
</p>
</s1>
Index: src/xdocs/framework/what-is-a-composer.xml
===================================================================
RCS file: /home/cvspublic/jakarta-avalon/src/xdocs/framework/what-is-a-composer.xml,v
retrieving revision 1.4
diff -u -r1.4 what-is-a-composer.xml
--- src/xdocs/framework/what-is-a-composer.xml 31 Jan 2002 15:43:52 -0000 1.4
+++ src/xdocs/framework/what-is-a-composer.xml 13 Feb 2002 16:35:56 -0000
@@ -15,7 +15,7 @@
<s1 title="Introduction">
<p>
In Avalon, Composable is defined as an active entity that controls
- or uses Components. It's best analogy is that of a musical composer.
+ or uses Components. Its best analogy is that of a musical composer.
The musical composer chooses what instruments (Components) by their
role in the symphony (system) and tells them which notes to play.
</p>
@@ -71,7 +71,7 @@
<p>
Sometimes you will have several Components that function in the same role.
For those cases, you will use the ComponentSelector to choose the exact
- one you need. The best way to describe it's proper use is the scenario
+ one you need. The best way to describe its proper use is the scenario
described here. You have several formatters that have the same Role:
to take an input document and format it according to the rules in the
individual Component implementations. One formatter may take a text file
@@ -107,7 +107,7 @@
Both the ComponentManager and the ComponentSelector require you to
release your Component when you are done with it. The method used
to do this is "release". One way of handling this is to use the
- try/catch/finally construct. Four your convenience, the following
+ try/catch/finally construct. For your convenience, the following
code can help:
</p>
<source>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
