Run update-copyright.py

README: Point to icalendar and other pre-existing libraries

icalendar seems to be the only one that is serious.  I'll take a
deeper look into their code and see if pycalendar is worth
maintaining.

README.rst: Add a symlink for GitHub rendering

README: Use a standard link instead of :RFC:`...`

PyPI doesn't like the :RFC: role, and distutils gives the unhelpful:

  $ python setup.py check --restructuredtext
  running check
  warning: check: Could not finish the parsing.

Using a standard link avoids this issue.

Major restructuring to get automatic decoding/encoding

Storing raw iCalendar data or unfolded lines is silly.  We should only
store native Python types, and serialize/deserialize as needed.  This
monster commit reworks the whole package to make this possible, adding
sub-packages for a number of data-types, properties, and components
defined in RFC 5545.  The conversion is not complete yet, and there
are a number of placeholder comments waiting to be filled in still.

Some of the test output changed because now that we serialize from
scratch, we lose information about the input that was unimportant
(e.g. GEO precision is now rounded up to 6 decimals, properties are
re-ordered inside their component, etc.).

MANIFEST.in: Add AUTHORS to the manifest

This should have happened after 36813e4 (Run update-copyright.py,
2013-06-30).

Remove - and : from example DTSTAMPs

RFC 5545 does not use these separators (unfortunately) in their dates
and times.  See sections 3.3.4 (Date), 3.3.5 (Date-Time), and 3.3.12
(Time), which specify:

  date               = date-value
  date-value         = date-fullyear date-month date-mday
  date-fullyear      = 4DIGIT
  date-month         = 2DIGIT        ;01-12
  date-mday          = 2DIGIT        ;01-28, 01-29, 01-30, 01-31
                                     ;based on month/year

  date-time  = date "T" time ;As specified in the DATE and TIME
                             ;value definitions

  time         = time-hour time-minute time-second [time-utc]
  time-hour    = 2DIGIT        ;00-23
  time-minute  = 2DIGIT        ;00-59
  time-second  = 2DIGIT        ;00-60
  ;The "60" value is used to account for positive "leap" seconds.
  time-utc     = "Z"

entry: Add parameter parsing to lines

Split the initial key/params/value parsing into its own function to
keep Entry._parse from growing unwieldy.

entry: Add Feed.get_geo for parsing the GEO field

This is library-level code, so it should go in the library.

entry: Add a docstring to Feed.get_text

Pointing people towards the TEXT specification.

Run update-copyright.py

test/aggregate.py: Add a Map class for persistent streams

Using a class method as a processing function allows you to keep open
file handles (and similar processor state) between feeds.

test/aggregate.py: Add an example aggregation script

This is how you use the library :).

test/data/bootcamps: Add a whole bunch of SWC boot camp feeds

This gives us lots of example feeds to aggregate.

test/data/geohash.ics: Separate lat/lon with a semicolon

From RFC 5545, section 3.8.1.6 (Geographic Position):

  Value Type:  FLOAT.  The value MUST be two SEMICOLON-separated FLOAT
      values.

entry: Die unless we're parsing a version 2.0 iCalendar

RFC 5545, section 3.7.4 (Version) describes this text field.  Until I
actually see something using using the (minver ";" maxver) syntax,
I'll just require everything to be version 2.0.

entry: Adjust entry parsing to handle nested entries (BEGIN & END)

Now Entry can parse a whole VCALENDAR, and return a nested tree of
Entry instances.

This also makes Feed a subclass of Entry.  The new entry BEGIN/END
parsing is derived from the old Feed BEGIN/END parsing.

entry: Hash entries by their UID (when possible)

From RFC 5545, section 3.8.4.7 (Unique Identifier):

  Conformance:  The property MUST be specified in the "VEVENT",
      "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components.

README: Add installation and testing advice

README: Flesh out the description with links to other aggregators

Unfortunately, none of the existing aggregators are libraries.

MANIFEST.in: Add a basic manifest

We don't have any READMEs under test/ yet, but I imagine we will
eventually.

setup.py: Add a boilerplate setup.py

.gitignore: Add the usual suspects

.update-copyright.conf: Add copyright configuration

Use my external update-copyright package to maintain copyright blurbs.

http://pypi.python.org/pypi/update-copyright/

entry: Make Entry a subclass of dict

This gives us the familiar interface, and moves key/value processing
to a one-time-per-entry loop in ._fill_dict().

entry: Add Entry.process() and .get*()

Because we will definitely want a Pythonic API to access entry items.

feed: Use splitlines() instead of split('\r\n') in Feed.process()

The specs require '\r\n', but we don't have to be that strict.

aggregator: Escape VERSION and PRODID

From RFC 5545, sections 3.7.3 (Product Identifier) and 3.7.4
(Version), these are both text fields.

text: Add escape() and unescape() for RFC 5545 compliance

aggregator: Add processors field for post-fetch processing hooks

feed: Turn Feed into a set of entries

entry: Add an initial Entry implementation

feed: Only fetch if we haven't already (or if we're forcing a fetch)

aggregator: Add an initial Aggregator implementation

Currently broken pending support for `for entry in feed`.  The version
and product identifier fields are required, as specified in RFC 5545,
sections 3.7.3 (Product Identifier) and 3.7.4 (Version).  They'll also
need to have special characters (e.g. commas) escaped, but I'll get to
that later.

feed: Implement feed.fetch()

Add __version__, __url__, and USER_AGENT to the package namespace, so
we have a useful user agent to use when fetching.  The fetch code can
hard-code UTF-8 as the feed charset, because RFC 5545, section 6
(Internationalization Considerations) reads:

  Applications MUST generate iCalendar streams in the UTF-8 charset
  and MUST accept an iCalendar stream in the UTF-8 or US-ASCII
  charset.

From a character conversion standpoint, that means we can always use
UTF-8, because US-ASCII is a subset of UTF-8.

test/data/geohash.ics: Pull out geohashing example from Feed doctest

This makes it easier to reuse the test data in other locations.

Also escape commas in the data.  From RFC 5545, section 3.3.11. Text:

  The "TEXT" property values may also contain special characters that
  are used to signify delimiters, such as a COMMA character for lists
  of values or a SEMICOLON character for structured values.  In order
  to support the inclusion of these special characters in "TEXT"
  property values, they MUST be escaped with a BACKSLASH character.

feed: Stub out the Feed class

Begin versioning under the GPLv3