Technical Documentation

The event site database is currently in its first draft stage.  It is "functional" for data entry entry and editing, with reports.  Please, use, abuse, take notes, observe and report.
Attempts were made to use other systems to manage a list of venue addresses. 
Excel has the problem with version control right out of the gate, and since 2011, compatibility has become an issue with the .xlsx extension.
Google Sheets was pondered and started.  Almost immediately, Google added and removed features that halted further development out of frustration.
We also looked at Google Maps which some groups have leveraged to display fight, fence, and archery practices.  We felt that privacy issues were not being met.
Research was looked at using a PHP framework, like a CMS or WordPress with extensions.  I just thought that they were way too complex for our needs and could come up with something adequate more quickly.
The result is the work of months of thought, a first attempt, more thought, some peer pressure, a muse, and weeks of coding.

Data Structure

Data is stored in either in a MySQL database or as files in a data folder.
Only registered users have direct access to modules that use the MySQL database, and additions or changes made by them are signed with their user id.
Data entered on the Anonymous page is stored as XML documents.  Although anonymous, each file contains IP address information for abuse tracking.

• — header
  Each venue is defined by what-you-call-it and where-is-it.  Extra information, who to contact, and how to contact them is just bonus.  Anything more is just details.
  Users can add, edit, and delete to their hearts' content.  Deleted venues can be restored by the DB admin.
• — detail
  Conversations (private/public), amenities, and photos are stored together in a separate table from the venue header data.
  Conversations are meant to record that the venue was contacted on this date, they talked to this person about this venue on that date.  What they discussed is a matter of preference whether they want to make public or private.  Some venues give special rates to not-for-profits that they don't want out in the wild.
  Amenities are a room-by-room accounting of dimensions and features.  Checkboxes are provided to allow searches on features.
  Photos must be JPEG images because they are reduced to 800×600 to conserve space and to make resonable assurance that the photo was not just snatched or spammed.  If the file is not a JPEG, it will be rejected.  Don't try to rename a PNG or GIF file to a .jpg; it won't work.  The name of the original file and a description are kept with and displayed with the photo. 
• — user list
  Current volume expectations are about 50 users with one or two new or retired users per month.  At those volumes, the data administrator can directly maintain user access.
  The username and password, privileges and permissions are stored in the clear, subject to technical review.
  To enter the system, the user needs to enter their username and password just once, and they have access until they close their browser.
• — anonymous entries
  Users in a hurry, or those without a username, may use the anonymous entry page to make a quick post to get the ball rolling for a new entry.  There is a description field and a bunch of buttons to confirm specific amenities.
  The data is stored in an XML file.  The description field in the file is called txtBodyHtmlArea, and the data gathered from the click buttons are stored in a field called txtClickInfo.  Also stored in the file are countermeasures from spam and abuse.  I gather the IP address and post a cookie code.
• — photos
  Photos must be in JPEG format.  The file is reduced to 800×600 to conserve space.  If the file is not a JPEG, it will be rejected.  Don't try to rename a PNG or GIF file to a .jpg; it won't work.  This is to make sure that the photos were taken by you and not just stolen from Google® Streetview™.

Data Entry

• — Anonymous submission
  Name and describe the venue.  Click a few buttons.  Hit submit.  What could be easier?
• — Bucket entry
  Each anonymously submitted venue must be entered into the system by a registered user.  Just confirm that the address is not already in the system and move on.  If the entry is a duplicate, delete it and go to the next one.  If the entry is rude or nonsense, banish the user.  They will not be able to make another entry until they apologize.  Apologies are recorded.  The data administrator has the power to exile the user if they have to apologize a lot.
• — Add-edit entry
  Full featured data entry.  Change GPS location.  Add conversation data.  Add amenities.  Add photos.  Then delete them.
  If you didn't make the entry, then you cannot edit them, but you can add to them.

Security

I have taken certain precautions to prevent the data gathered from getting into the wild.
In my mind, this is not our data.  We have gathered it from friends.  We have to protect it on their behalf. 

• — log in authentication
• — Basic Access Authentication
  Basic Access Authentication uses a browser request for username and password to access the site.  It works fine for Chrome, Edge, and Safari, but it is considered obsolete by Facebook and Firefox.  The problem is that the username and password are transmitted in the clear allowing sniffers to gain access to the site.
• — Digest Access Authentication
  Digest Access Authentication is the next step up from basic access authentication.  It is more secure and reportedly compatible in all new browsers that currently block Basic Access Authentication.  This is the type that is implemented pending the technical review.
• — private conversations
• — AES encryption
  Conversations considered private are encrypted using AES.  This uses a passphrase as a key to lock or unlock any conversation that needs to be kept private.  The passphrase is not saved anywhere on the server.  Any encoded data needs to be decoded with the original passphrase.
• — cookies
  It is possible that the passphrase is stored in cookies.  Don't toss your cookies.
• — metadata
  Since the system cannot examine encrypted for the purpose of searching and filtering, certain standard check boxes are stored in the clear. Search for meeting spaces, fight practices, or large outdoor events to your heart's content.
• — anonymous access
  All file names are obfuscated to hinder non-user access. Files that contain the data gathered from anonymous entries, as well as the photos, are stored using a non-sequential naming convention.  The folder is likewise not accessible as a folder.  But, if you happened to know the file name, you probably already have signed in to get it.

Future Development

• — Improved map interface (DONE)
  At the time of the initial design of the page, I got the impression that the API key was not free and compicated to implement.  So I made my own interface that leveraged the anonymous map access.  It worked the way the old MapQuest interface used to work.  Now that I have my own API key, I have started looking into using the map interface that you may be more familiar with.  But the object is not at all the same so there will be some tweeking of the interface before it is ready.
• — Improved security (DONE)
  Basic Access Authentication is obsolete, already.  It works in older browsers like Chrome, Internet Explorer, and Safari, but Firefox and Facebook reject it outright.  Digest Access Authentication is live.  There was a problem where some apps did not perform the log in procedure, but the login failure page displays the workaround. 
  The original plan was to secure the site using two factor authentication which is well demonstrated in this demonstration.  I just felt that it would be too over-the-top for our purposes, but something to look into if this gets too big.
• — Reports
  The whole plan for this database was to get a set of sites that we can contact for events of a particular character.  Security was job number one, as we don't want to let a price list or certain other information out into the wild.  I will need to work with someone knowlegeable in visual design regarding how to build this.
• — Menu
  There are currently only four pages planned in the site.  I have put all the links in a floor menu.  We'll have to see if that is a problem.
• — Technical and Practical review
  These pages are a first draft of a venue database and a contact management system.  I have put forth a best effort based on what some people have wanted to see in the site, but after trying it and seeing what they do and do not like about the methodologies, changes will need to be made. 
  At some point, the site will be released to the kingdom for hosting on their site. It is currently being hosted on my personal site. 

Built by Philip Young inspired by a post on Facebook.