Edited wiki page AdaptorsInRelationToConnectors through web user interface.
diff --git a/AdaptorsInRelationToConnectors.wiki b/AdaptorsInRelationToConnectors.wiki
index 2899f8d..879e912 100644
--- a/AdaptorsInRelationToConnectors.wiki
+++ b/AdaptorsInRelationToConnectors.wiki
@@ -19,11 +19,13 @@
Item 2 requires noticing updates to the repository, but also being able to handle failures from the GSA. Many connectors need to keep large amounts of state to correctly notice updates. This led to an initiative to provide large, high-availability data stores for use with connectors. That means that there can be three high-availability data stores in the system: the repository, the connector, and the GSA. To handle failures, the connector manager has a checkpoint system that requires connectors to be able to save and restore checkpoints in case of errors. For some repositories, these requirements are easy to deal with, however, for others they have required considerable amount of code. If any point in the repository’s history cannot be easily referenced (i.e., there isn’t a single identifier across the entire repository) this becomes a major problem.
-Item 3 causes errors and bugs to be persistent. When an intermittent error occurs during indexing the GSA will not index the file. The only way to correct the error is by restarting a full, overwriting push of repository and hoping the second time fairs better. File system connector tests have shown that for document sets over 100,000, it is common to have missing documents.
+Item 3 causes errors and bugs to be persistent. When an intermittent error occurs during indexing the GSA will not index the file. The only way to correct the error is by restarting a full, overwriting push of repository and hoping the second time fairs better. File system connector tests have shown that for document sets over 100,000, it is common to have a missing document.
+
+This is not meant to dis connectors. Instead, it is meant to define the problems to be solved. The connector design is highly reasonable and does prove to work, but we want connectors to be easy to write and use, and the listed items slow development and comprehension.
= The Lister/Retriever Model =
-The lister/retriever architecture of adaptors provide many advantages over using content feeds: simplicity, scalability, self-healing, stateless, transparent operation (easy monitoring and debugging), and it reuses existing infrastructure.
+The lister/retriever architecture of adaptors provide many advantages over using content feeds when you can randomly access content: simplicity, scalability, self-healing, stateless, transparent operation (easy monitoring and debugging), and it reuses existing infrastructure.
The original expectation was that adaptors would have a slight performance loss when using only a single GSA. Since adaptors have the ability to scale to multiple GSAs, it was thought to likely be worth the performance penalty in the single-box setup. However, testing revealed that adaptors can actually be faster than connectors when the repository is not the bottleneck. For a file system repository containing no documents requiring text conversion and where latency could have had an impact, the adaptor performed 20% better than the corresponding connector. This in no way means there will always be a performance gain, but instead merely that it is possible and has happened.
