Edited wiki page WhatAreAdaptors through web user interface.
diff --git a/WhatAreAdaptors.wiki b/WhatAreAdaptors.wiki
index f15e9dd..604b6cd 100644
--- a/WhatAreAdaptors.wiki
+++ b/WhatAreAdaptors.wiki
@@ -6,7 +6,7 @@
For each repository you want to search with your GSA, you need some way to provide that repository's data to your GSA. If your repository provides an HTTP website, then no special solution should be necessary, as the GSA should be able to crawl your repository like any other website. However, sometimes you want closer integration with the GSA or your repository doesn't provide a website and thus you need solution to provide its data to the GSA.
-There are many ways to model and communicate your repository's contents to the GSA, and Adaptors are one of them. For other possible solutions, look into [http://code.google.com/p/googlesearchapplianceconnectors/ Connectors] and [http://code.google.com/apis/searchappliance/documentation/614/feedsguide.html Content Feeds].
+There are several ways to model and communicate your repository's contents to the GSA, and Adaptors are one of them. For other possible solutions, look into [http://code.google.com/p/googlesearchapplianceconnectors/ Connectors] and [http://code.google.com/apis/searchappliance/documentation/614/feedsguide.html Content Feeds]. Adaptors are attempting to replace the Connector model and are much easier to learn and develop, but Connectors are the current standard and support older GSA versions. Content Feeds should be used when the repository does not provide random document access and instead _only_ provides changes occurring in the repository.
All Adaptors use the Adaptor Library to communicate with the GSA. The Adaptor Library defines much of the architecture of the Adaptor and controls communication with the GSA. Since all Adaptors share the Adaptor Library, the rest of the discussion will relate to the Adaptor Library and what it provides to Adaptors.
@@ -14,10 +14,12 @@
Shallow learning curve, incremental development, and performance are the core design forces of the Adaptor Library. We want you to be able to create a working Adaptor within a day, incrementally add extra features, and still be able to tune for high performance.
-The APIs are designed where you were can ignore pieces you don't need, and only learn them once you need them. This makes the various features separate and orthogonal to each other. To implement a basic Adaptor, you only need to implement two methods know the basics of five different classes. In some ways, five classes may seem like too many, but they all serve an obvious function and you only need one method from each.
+The APIs are designed where you were can ignore pieces you don't need, and only learn them once you need them. This makes the various features separate and orthogonal to each other. To implement a basic Adaptor, you only need to implement two methods and know the basics of five different classes. In some ways, five classes may seem like too many, but they all serve an obvious function and you only need one method from each.
Performance is a concern for the Adaptor Library, but it does come second to ease of use. However, even without giving up how easy the library is to work with, the library has been able to achieve high performance and easily handles millions of documents; we generally expect the GSA or the repository to be the bottleneck.
+In order to make Adaptors easy to create, we have pushed to make them stateless (or mostly stateless). Individual Adaptors can still store state if necessary, but we discourage it. When stateless, Adaptors are resilient, use little memory, are easier to code, and are easy to use in a high availability solution. When optimizing for performance, we find it reasonable to use a minimal amount of state in memory (like a date or revision number), but the system is designed to work even if such state is lost or corrupted.
+
= Adaptor Architecture =
Adaptors have two main pieces and a third piece for non-public repositories. The two main pieces are a _lister_ and a _retriever_. With just those two pieces the core architecture is formed and a working Adaptor can be created. The third piece performs authorization.
