Obsoleted by bug MKWS-130
authorMike Taylor <mike@indexdata.com>
Thu, 27 Feb 2014 15:27:07 +0000 (15:27 +0000)
committerMike Taylor <mike@indexdata.com>
Thu, 27 Feb 2014 15:27:07 +0000 (15:27 +0000)
TODO [deleted file]

diff --git a/TODO b/TODO
deleted file mode 100644 (file)
index f33ef96..0000000
--- a/TODO
+++ /dev/null
@@ -1,87 +0,0 @@
-*** 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.
-