update docs

README.md

@@ -9,7 +9,7 @@ Main features:
 - quickly mark a registered person as an attendee
 - easy way to add a new person, if it's already known from a previous event or if it's a completely new person
 - can import Eventbrite CSV export files
-- RESTful interface
+- RESTful interface that can be called by third-party applications (see the https://github.com/raspibo/event_man/ repository for a simple script that checks people in using a barcode/QR-code reader)
 - ability to run triggers to respond to an event (e.g. when a person is marked as attending to an event)
 
 See the *screenshots* directory for some images.

docs/DEVELOPMENT.md

@@ -1,9 +1,9 @@
 Definitions
 ===========
-:
+
 - **event**: a faire, convention, congress or any other kind of meeting
 - **registered person**: someone who said it will attend at the event
-- **attendee**: a person who actually *show up* (checked in) at the event
+- **attendee**: a person who actually *show up* (is checked in) at the event
 
 
 Paths
@@ -50,7 +50,7 @@ The paths used to communicate with the Tornado web server:
 - /login - login form
 - /logout - when visited, the user is logged out
 
-Notice that the above paths are the ones used by the webapp. If you plan to use them from an external application (like the _eventman_ barcode/qrcode scanner) you better prepend all the path with /v1.0, where 1.0 is the current value of API\_VERSION.
+Notice that the above paths are the ones used by the webapp. If you plan to use them from an external application (like the _event\_man_ barcode/qrcode scanner) you better prepend all the path with /v1.0, where 1.0 is the current value of API\_VERSION.
 The main advantage of doing so is that, for every call, a useful status code and a JSON value is returned (also for /v1.0/login that usually would show you the login page).
 
 Also, remember that most of the paths can take query parameters that will be used as a filter, like GET /events/:event_id/persons?name=Mario