You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Laura Dean <la...@oryxa.com> on 2002/02/13 17:53:00 UTC
Framework documentation (~200-line diff)
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
Laura
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Framework documentation (~200-line diff)
Posted by Peter Donald <pe...@apache.org>.
Applied - thanks!
On Fri, 15 Feb 2002 03:45, Laura Dean wrote:
> 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
--
Cheers,
Pete
-----------------------------------------------
| If you turn on the light quickly enough, |
| you can see what the dark looks like. |
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Framework documentation (~200-line diff)
Posted by Laura Dean <la...@oryxa.com>.
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
Re: Framework documentation (~200-line diff)
Posted by Peter Donald <pe...@apache.org>.
On Thu, 14 Feb 2002 03:53, 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:
Thasnks for this. Unfortunately it got mangled when you sent it through the
mailserver/mailclient. Would you be able to send it as an attachment rather
than inline? Thanks!
--
Cheers,
Pete
-------------------------
All things considered,
insanity may be the only
reasonable alternative.
-------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>