Add simple PubSub code adapted from jQuery manual.
[mkws-moved-to-github.git] / TODO
diff --git a/TODO b/TODO
index 1cf21b9..f33ef96 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,25 +1,47 @@
-*** GENERAL ***
+*** MKWS ***
+
+       Architecture: separate objects for each widget
 
-       We need additional image-URL fields in our records -- in the
-       connector framework, in the Torus record's capabilities and
-       elsewhere. Figure out what's needed, and who needs to do it.
+       Architecture: translucent configuration, with global values
+       shining through where a specific widget provides no local
+       value.
 
-       Can the IRSpy toroid be made to return a meaningful capability
-       field?
+       Architecture: decouple related elements using
+       publish/subscribe. (Jakub will probably do this.)
 
-       Metasearch all targets and see what happens. Figure out why it
-       goes wrong.
+       Architecture: managed widgets held in the Torus. Maybe.
 
-       Get Charles to remove the testing proxy-IPs from open-access
-       databases.
+       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().
 
-       Fix the Torus's timed refresh to run on its own in the
-       background, rather than waiting until the next time a request
-       is made after the
-       refresh-time has expired.
+       Create a logging widget which displays the output of debug().
 
+       Check that library selection (authentication) by hostname
+       works for MKWS.
 
-*** 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 an Amazon cover-art widget.
 
-       Do target selection by UDB rather than ZURL. Needs SP changes.
-
-       We will want a facets-only widget, e.g. to list top authors
-
        Visualisation widgets e.g. pie-chart of authors, bar-graph of
        records Generate embedded SVG? Does that even work?
 
 
        Write about interesting new widgets on the Index Data blog.
 
-       Widget gallery
-         * Mainly a marketing thing on mkws.indexdata.com
-         * May also have a role in widget creation in MKAdmin
+       Make a widget gallery as a marketing thing on
+       mkws.indexdata.com
 
-       Architecture:
-         * Separate objects for each widget
-         * Translucent configuration
-         * Decouple using publish/subscribe
-         * Managed widgets held in the Torus
-         * 3rd party widget platforms
+       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, we want to expose capability
+       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.
 
-       Auto-widgets should be able to include limits (as a full set
-       of MK2-like widgets does in order to implement facets).
-
-       Auto-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.
-
        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.
 
-       Check library selection by hostname works for MKWS.
-
        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.
 
-       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().
-
-       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.
-
-
-*** MKADMIN ***
-
-       Add a capability facet to MKAdmin. The right way to do this is
-       to refactor the current hardwiry facet code to be more
-       data-driven, then add a configuration element to include
-       capabilities as a facet.
-
-       Make MKAdmin able to filter target list on whether we have
-       access: that is, to targets that either are open-access or we
-       have credentials or an IP proxy for.
-
-       Provide "select all targets" to they can be added.
-
-       Add batch edit on all targets found by the current search.
-
-       Superuser field should not be mandatory.
-
-       Add an "Act As" link on the Edit Library page.
-
-       When making a new user-access record, default the displayName
-       to that of the ibrary that owns it.
-
-       In end-user record, username and password should not be
-       mandatory any more. (Perhaps it should be mandatory to have at
-       least one of u/p, IP range, hostname, etc.)
-
-       We want a way to let customers change the Index Data branding
-       of the MKX front page, as well as the logo at top left of the
-       MasterKey UI itself. Along with that, we could let them change
-       CSS.
-
-       Indent second and subsequent lines of long facet names
-
-       Keep selected facets when narrowing by search, etc. NOT URGENT
-
-       Lose the search function and the A-Z list from the Categories
-       and User Access tabs.
-
-       Lose ALL the left panel options for the categories tab.
-
-       In the library list, rename "Act as this user" to "Act as".
-
-       We need only one add-new-field name/value pair at the bottom
-       of the screen, not three.
-
-
-*** MKAdmin-- ***
-
-       Lose Target Origin and Type columns from list.
-
-       Lose the A-Z list.
-
-       Remove "changed in last NUMBER days" from search form
-
-       Remove the the Edit facility and the New button from the
-       categories tab. Keep the category_id column, for some
-       reason. (Although I bet if I removed it neither Seb nor D
-       would notice.)
-
-       Make the User Access tab display the single end-user record
-       for editing immediately. Remove everything that doesn't need
-       to be there.
-
-       Remove all help from MKAdmin until Seb sends help texts that
-       he is happy with.
-
-       D will get back to me with a detailed specification of which
-       reports to include in the Reports tab.
-
-       In the target list, get rid of "Show record", make the target
-       title a link to the edit page, and discard the edit column
-       completely.
-
-       In the edit page, lose all the top icons.
-
-       D will give me a list of target fields to retain in the
-       MKAdmin-- edit page. It may be just target name, categories
-       and credentials.
-
-       BIG CHANGE: lose the edit-form distinction between inherited
-       and local values. Have a single column of editable values and
-       override only those that are actually changed.
-
-       Lose the Create Target facility (from left panel and bottom
-       row).