guides/developer/Developer-guide.md

@@ -5,90 +5,10 @@ Welcome to the Developer’s guide.
 This document will guide you through the stages of component development and teach
 you how to develop your own components in just a few minutes.
 
-## [Coding guidelines](http://rubydoc.info/github/Arachni/arachni/file/HACKING.md)
-
-
-This should be your first stop for module development, it will give you
-the skinny on hacking around with the framework.
-If that’s not enough to get you started there’s no need to worry, the
-next chapters will explain the process in detail.
-
-## Component development
-
-Every modular aspect of Arachni is abstracted in the form of
-*components* .
-As long as components lie within their root directories (```/modules``` for
-modules, ```/reports``` for reports and ```/plugins``` for plugins)
-there is no limitation as to how they can be grouped together.
-
-Arachni scans these directories recursively and loads all Ruby (```*.rb```)
-files as components.
-However, since there will often be a need to include helper Ruby files
-(like classes, modules, etc) components are allowed to include such files under
-a directory with the same name as the component that utilizes them.
-
-For example, the *Proxy* plugin which has a filename of ```proxy.rb``` holds its
-helper classes under the ```proxy/``` directory.
-
-Ruby files identified as helpers will not be loaded by the framework.
-
-The easiest way to start developing your own component is to pick an
-existing one which is closer to your needs and modify it to fit your
-requirements.
-
-### Path extractors
-
-Path extractors are used by the spider and their only job is to extract and return
-a list of paths from the provided HTML document.
-
-### [Modules](http://support.arachni-scanner.com/kb/writing-modules/)
-
-Modules are the most important type of component in the framework.<br/>
-They assess and log vulnerabilities or other entities of interest during
-the scanning process.
-
-They operate under the scope of a page and are passed each page that needs to be
-audited.
-
-They are split into 2 categories, _audit_ (active)  and _recon_ (passive).
-Audit modules actively engage the webapp via its inputs while recon modules
-perform discovery related operations like checking for certain patterns in
-the page body or look for interesting files and directories on the server.
-
-
-### [Reports](http://support.arachni-scanner.com/kb/writing-reports/)
-
-Reports are used to export the results of the audit in a desired format or fashion.
-
-Report components are currently used to generate files (html, txt, xml,etc) however
-there are no restrictions as to their exact behavior; meaning that anyone can
-develop a report component that saves the scan results to a database, transmits
-them over the wire, etc.
-
-### [Plugins](http://support.arachni-scanner.com/kb/writing-plugins/)
-
-Unlike the two previous types of components plug-ins are demi-gods.<br/>
-Each plug-in is passed the instance of the running framework to do with
-it what it pleases.
-
-Via the framework they have access to all Arachni subsystems and can
-alter or extend Arachni’s behavior on the fly.
-Plug-ins run in parallel to the framework (and each other) and are executed right before
-the scan starts.
-
-### [RPCD Handlers](http://support.arachni-scanner.com/kb/writing-rpcd-handlers/)
-
-RPCD Handlers are server-side components which have direct access to their parent
-Dispatcher and whose API can be exposed via the regular RPC interface.
-
-These components provide a way to extend the server-side functionality with
-extra features.
-
 ## [Core API](http://rubydoc.info/github/Arachni/arachni)
 
 Automatically generated documentation of the Arachni code-base.
 
 ## [[RPC API | RPC API]]
 
-Detailed documentation on using the RPC API to interact with the Arachni
-servers (Dispatcher/Instance) or write your own client.
+Documentation on using the RPC API to interact with Arachni.