!!!Risten2 meeting

* work done during the summer
* design issues
** API-like things
** first UI
* work ahead
* guidelines and routines
* schedule/timeline

!!!Work Done During The Summer

Børre did a lot of work before going on vacation, demo server running on:

http://www.divvun.no:8080/exist/apps/risten2/index.html

Tomi also has a demo server running on his own computer:

http://129.242.102.145:8080/exist/apps/risten2/index.html

Børre:
* studying other examples (Shakespeare)
* wikibooks example of searching the periodic table (http://en.wikibooks.org/wiki/XQuery/Incremental_Search_of_the_Chemical_Elements)
* searching using AHAH (Asynchronous HTML and HTTP)
* learned how to apply them to the Risten2 code
* typing in the search field trigger a search, returning a hit list below
* clicking on one of the links presents the corresponding article on the right
* checkbox for searching from the beginning instead of anywhere, and pop-up menu 
  of dictionary list
* a lot of studying, one week of implementation
* fixed the dictionary sources:
** Mechanical terms/eng: marked as fin, changed to eng
** some of the giellatekno dicts lacked source language - added
   (together with Ciprian)

Tomi:
* struggling with getting the hit list, but Børre has done that well
* modularising the code, and making it more general
* updated the templates and config stuff to use the newest eXist datatypes
  and apps functionality
* rewrote the search function to use the new map datatype - ''much'' faster!
** Børre had used two searches to get the data needed
** with the map data structure, all the needed data can be held in memory
   and accessed much faster
* the new templates handles the requests (http attributes and query parameters)
  and turn them into function parameters/arguments

The map data structure contains the following data:

{{{
let $hits := risten:do-query($query, $dicts)
    let $store := session:set-attribute($risten:SESSION, $hits)
    return
        map:entry("hits", $hits)


    for $hit in subsequence($model("hits"), $start, 10)
}}}

Regression from Børre to Tomi versions:

* search for "stempel"
* Børre's version returns three matches:
 ''stempel; stempelring; stempelstang, veivstang, -stongn, råde''
* Tomi's version returns one match: ''stempel''
* they should both be using the same dictionary data/sources, and should have returned the same set of hits

__TODO:__
* add support for testing our code (regression, unit testin). See the eXist code
  for examples of how to do this.

!!!Design Issues

!!Code and data structures

The map data structure above should be enhanced with the dictionary ID, so that each hit has an ID associated with it.

Tomi: rather a map datastructure "dicts" to store where the hits were found.

Basic question:
* what should be done on the eXist server, and what should be done in the brwoser?

Example case: __highlighting which dictionaries go with a certain hit__

* when the user clicks a hit, two things shoujld happen:
** the corresponding articles should be displayed on the right (with dictinary names as headers & separators between the entries)
** the dictionaries in which the hit is found should be highlighted on the left

The dictionary high-lighting is probably best done by the browser, but requires that we have the necessary info/data available in the browser, ie that all hits have a datastructure associated with them, containing a list of matching dictionary ID's.

Where should we draw the border between what is done on the server, and what is done in the browser?

Roughly:
* data fetching is done on the server
* presentation manipulation and display is done in the browser
* store dictionary ID in the html tag in the results (=hit list)

__TODO:__
* add ID (and metadata) into xml sources (it is in the metadata files in
  risten1, but probably not in the real xml source files)
* add the display name to the metadata

!!i18n & l10n

* display name in several languages?
* UI in several languages
* all this is the "presentation language" or UI language

Presently there is a very light-weight need for l10n, but there is some. eXist has now support for i18n, which we need to turn on.

__TODO:__
* add i18n support to risten2
* add l10n of dictionary names
* add l10n of dictionary articles
* add a user interface for switching UI language
* standardise on ''one'' way of setting default/fallback language for all types
  of i18n data (see [the eXist documentation|http://demo.exist-db.org:8098/exist/apps/demo/examples/special/i18n-docs.html])

!!API-like things

!Standardised and generalised calls

* one set of database calls used for all user agents
* user agents can be at least the following:
** regular desktop web browser
** tablet browser
** phone browser
** translation agents
** in-app dictionary agents
** dict-protocol agents (needs to be wrapped in a dict-protocol front-end)
** idea for the future: download services in standardised formats???

!Net lag issues (asynchronisity things)

Is this a real issue? No, Tomi don't think so. Easy to add if needed.

To not confuse the user and the server, don't send a new query until the data from the previous query is received. See the JS in the Wikibooks example (see link above). It should be easy to add/implement.

!!First UI

The first UI is for desktop browsers. See earlier mockups.

Search everywhere in the word with an option to restrict the search to the beginning of the string? Also good for name searches, and trunkated searches.

The search is a case insensitive regex search now.

* the search should be case insensitive
* the search should be bound to the beginning of the string by default
* there should be an option to match the search string anywhere in the words

!!!Guidelines And Routines

* weekly meetings
* code reviews
* systematic tests: unit tests, regression tests
* svn commits at least every evening

Who is doing what:

* coding - Tomi
* setting up test infra - Børre
* code reviews - Børre
* weekly meeting - Tomi, Sjur, Børre

!!!Work Ahead

# testing infra
# i18n
# add dictionary list
# add search restriction based on dictionary selection
# improve article display

!!!Schedule/timeline

* code review Friday 17.8. 10.00 (Børre and Tomi)
* meeting Monday 20.8. 10.00 (Sjur and Tomi)