Instead of having lots of objects implement Comparable or Comparator,
pass the comparator in to the PriorityBlockingQueue.
This requires recreating the queue if the QueueHandler is ever changed,
but the previous behaviour resulted in an unstable/undefined ordering,
so it's probably better this way anyway.
This means that QueueItems no longer need to know about QueueHandler,
which makes me slightly happier.
This allows the logic to be expressed more nicely and tested
independently of the handlers. It also paves the way for a
bit of refactoring to reduce the number of random things
that need to be comparable...
Use Java8 date types for parser queue items. Fix the time check in
QueueHandler to check if the item has been queued for longer than
10 seconds, rather than if the item was created within 10 seconds
of the epoch.
Add IRCDataInEvent that presents an IRCReader.ReadLine object rather than just the line of data.
This gives us access to MessageTags (#19) and pre-tokenised lines in DataIn rather than everything neededing to tokenise themselves.
There are probably a few other events we want to expose messagetags on that we still don't.
Try to keep track of channel keys (Close Issue #108)
- Parses outgoing JOINs to try and guess keys before we get the MODE reply.
- Parsing algorithm based on Quakenet/Hybrid handling of keys.
- Keys are swallowed from the key-list for EVERY channel that is
to join, even if it is not needed, so you would need to use
"JOIN #Foo,#Bar,#Baz Foo,,Baz" to join keyed channels #Foo and #Baz.
- Key changes by mode +k and -k will be tracked.
- Ignores attempts to set the key as "*" if we know a "better" key.
- Side effect: If the key is actually set to "*" we can only learn it if that
is what we join with, or it gets changed to that from no-key.