*** MKWS ***

	Architecture: separate objects for each widget

	Architecture: translucent configuration, with global values
	shining through where a specific widget provides no local
	value.

	Architecture: decouple related elements using
	publish/subscribe. (Jakub will probably do this.)

	Architecture: managed widgets held in the Torus. Maybe.

	Architecture: "3rd party widget platforms". I seems to recall
	I copied this off one of Seb's lists on the flipchart, but I
	can't remember what it refers to. Can anyone?

	Allow debug() to be customised by setting a callback function
	that is passed the string rather than just giving it to
	console.log().

	Create a logging widget which displays the output of debug().

	Check that library selection (authentication) by hostname
	works for MKWS.

	Add library selection by secret key as an alternative to
	selection by user/pw. This is appropriate for
	security-conscious customers to embed in their own CORS-aware
	Apache2 configuration.

	Auto-executing widgets should be able to specifying limits (as
	a full set of MK2-like widgets does in order to implement
	facets).

	Auto-executing widgets should be able to include filters (as a
	full set of MK2-like widgets does in order to implement the
	Target facet). This can be used to implement target categories
	as well as the current cruder target-selection-by-ID facility.

	Do target selection by UDB rather than ZURL. May need SP
	changes, but we might already have the necessary functions.

	We will want a facets-only widget, e.g. to list top authors

	Make a demo widget that displays an image, like the "From the
	Digital Archive" panel of our Toronto Digital Library demo.

	Make a widget demo that displays the top-hit full record
	rather than a list of summary records. This can be used to
	pull in Wikipedia text to make the bulk of a topic page.

	Make an Amazon cover-art widget.

	Visualisation widgets e.g. pie-chart of authors, bar-graph of
	records Generate embedded SVG? Does that even work?

	Make am MKWS/Fresco demo by embedding widgets in our Koha
	installation. Get Wolfram to do this, and find out which parts
	of the process are cumbersome for him.

	Write about interesting new widgets on the Index Data blog.

	Make a widget gallery as a marketing thing on
	mkws.indexdata.com

	Maybe also use something like a widget gallery as part of the
	widget-creation facility in MKAdmin.

	Write integration guides for various third-party CMSs.

	In the widget builder (initially in MKAdmin and subsequently
	in a widget-building widget), we want to expose capability
	information (from ZeeRex or a Torus record) in a
	human-consumable form: "this target can sort by recency", that
	kind of thing.

	In the widget builder, we should be able to filter the targets
	available to the widget on the basis of what requirements the
	widget has, e.g. ability to sort by recency. The capability
	facet in MKAdmin may suffice for this.

	The widget-builder widget (WBW) should have a Save button that
	is customised by a callback, so that the widget in question
	can (for example) be copied into the clipboard, pasted into a
	nominated div, saved to a database or whatever.