This is a list of issues we have while implementing the Xesam interface for
Beagle, in some sort of priority-order:

* Hit Fields: Currently we can only return only a limited set of fields for
	hits. We need to support everything that we can as defined in the
	Xesam ontology draft. This work in progress (see src/Ontologies.cs for
	the current set of mappings)

	Also, How do we sanely set the default value for 
	session.vendorOntologies as 
	["xesam", "1.0", "$XDG_SYSTEM_DATA_DIR/share/ontologies/xesam-1.0"]

* Parsing: The parser should use QueryParts instead of the generating a search
	string. This should be pretty easy to implement.

	NOTE: Beagle doesn't support grouping of ANDs and ORs, it seems. We
	either need to make some drastic changes at lower levels (more R&D
	required), or break up at ORs and start multiple searches for a single
	Xesam search (this is ugly).

	NOTE2: The parser does not verify the input XML against the Xesam query
	schema

* User Searches: User queries are supported as a hack. We don't parse them
	at all. Since they're so similar to Beagle's native search language,
	this works for now.

* Fields/Sorting: We need the list of fields before we can handle these

* Threading: We need to verify that we've got locks where we need and that a
	blocking request does not block the adaptor as a whole

* HitsModified: Beagle does not have an equivalent signal, because it'd need
	to maintain a lot of state to track these changes. Instead, we just
	send a HitsSubtracted followed by a HitsAdded.

	This brings us to a whole different problem. GetHits(count) gets
	count hits after a HitsAdded event, sorted in the given order. Now
	what happens if a given set of htis are retrieved, then some are
	modified (or more are added). What does the next GetHits() return? The
	new set of hits, or the first count hits of _all_ hits added so far?

* Blocking searches: We stop blocking after the first OnFinished event. Maybe
	we need to wait for a few more before throwing a SearchDone

