From: Mike Taylor Date: Mon, 14 Apr 2014 14:53:33 +0000 (+0100) Subject: Remove the old 2013-06-24--todo file: everything we discussed and decided back then... X-Git-Tag: 1.0.0~962 X-Git-Url: http://git.indexdata.com/?p=mkws-moved-to-github.git;a=commitdiff_plain;h=bee7de28dcb507fc664ea22e6ac9fac84d8f359e Remove the old 2013-06-24--todo file: everything we discussed and decided back then has either been done, or we've decided to do something different --- diff --git a/notes/2013-06-24--todo b/notes/2013-06-24--todo deleted file mode 100644 index 6bdc1be..0000000 --- a/notes/2013-06-24--todo +++ /dev/null @@ -1,62 +0,0 @@ -Adam, Wolfram, Jakub and I just had a ninety-minute meeting to look at -MKWS (the MasterKey Widget Set) and discuss how to progress it. - -I won't bother trying to summarise the discussion, just the -conclusions. - -1. We really like the concept, though Jakub is wary about the danger - of reinventing the wheel. - -2. We're happy with the distinction between two levels of MK2 - integration: MKWS for entry-level HTML programmers; and more - sophisticated customers who want more control can roll their own - MasterKey Client based on MK2-UI-core. - -3. To avoid that wheel-reinventing, we want MKWS to itself be built on - the UI core. To pick a concrete benefit: Wolfram has invested some - effort to make MKWS multi-lingual; but had it been based on the UI - core, he could have put that work into the core, and all other MK2 - UIs would have benefitted from it. - -4. We plan therefore to re-engineer MKWS to use the UI core -- or, - which might be a faster route to the same destination, to redo the - MKWS work but starting from a core-based UI instead of from - JSDemo. (This is in accordance with the experimental nature of the - work we've been doing -- what we're currenty referring to as "the" - MKWS code is actually one of several threads within the - "experiments" directory.) - -5. Because we want to enable smooth demos at ALA this coming weekend, - we are NOT going to begin the re-engineering until after ALA, - instead concentrating on getting the current MKWS experiment to - work as cleanly as possible. - -6. We want to establishing some demo sites that use MKWS, ready to be - shown to prospective customers. We think the best approach is to - pick three sites that currently have no searching (for example, - Dennis's site and one of my own) and add minimal MKWS code to - each. Then Seb will be able to demo the small HTML/JS changes in - those sites. - -7. To make these demos work, we will need to solve the problem of - cross-site scripting, allowing those sites to make Service Proxy - requests. This is the top programming priority (and what I will - start working on as soon as I've sent this message!) - -8. After some back-and-forth, we decided that we would eliminate the - current use of jQuery. (We're not doing anything at all clever with - it -- basically just node-selection and HTML-building). Life is - simpler without the dependency, and the danger of colliding with a - different jQuery version in use on the customer's site. - -9. We'd like to have mkws.js include pz2api.1.js on its own, so that - the customer's HTML only has to do a single JS include. Not a big - deal, but it just makes the demos look more lightweight. - -10. We really like the explicitness of the configuration hash that - Wolfram's introduced, and the way it defaults intelligently when - elements of it are omitted (or indeed when the whole thing is - omitted). We'd like to add a config element that tells the results - page to pop up in front of the main website, like the Google CSE - results do on http://www.miketaylor.org.uk/ -