| 1 | MICHAEL'S LIST :-)
|
|---|
| 2 |
|
|---|
| 3 | /home/kjdon/public_html/michael (www.cs.waikato.ac.nz/~kjdon/michael) has some helpful docs - actually only one - the jni book.
|
|---|
| 4 | also see hints.tex and manual.tex in docs/manual - printed out too.
|
|---|
| 5 |
|
|---|
| 6 |
|
|---|
| 7 | * images from the server. currently we expect that they are on the same machine - the xslt puts in links to them. need a better way to get images that works remotely. so far do this for the colleciton icons. once document display is worked out better, do it for document images too.
|
|---|
| 8 | Then there is the generic associated resource retrieval. this will depend on document DTD and what xlinks we use for associated docs/resources. maybe the id of a resource is its http address if there is one, otherwise you get it through soap or in the xml.
|
|---|
| 9 | theres two routines in GSFile - base64EncodeFromFile() and base64DecodeToFile() which goes file <-> base64 string - can use these to put image etc into xml.
|
|---|
| 10 |
|
|---|
| 11 | * add the Gatherer code to cvs.
|
|---|
| 12 | I've been meaning to do this for ages, but never got around to it. The code is at www.greenstone.org/gatherer. talk to david.
|
|---|
| 13 |
|
|---|
| 14 |
|
|---|
| 15 | * Display stuff vs metadata
|
|---|
| 16 |
|
|---|
| 17 | When you get a service description, you also get a <display> element which has text strings for the service name, submit button, and any text needed for the parameters. (see query_messages)
|
|---|
| 18 |
|
|---|
| 19 | When you do a browse thingy, along with any classifier info you also get some metadata - Title (see browse_messages).
|
|---|
| 20 |
|
|---|
| 21 | Where do you draw the line between a display element and a metadata element?
|
|---|
| 22 |
|
|---|
| 23 | The full name of the service that is currently in the display could arguably be a metadata element.
|
|---|
| 24 |
|
|---|
| 25 | we need a consistent view of what is metadata and what is just a display element.
|
|---|
| 26 |
|
|---|
| 27 | all agents respond to a describe yourself message which retrieves metadata as part of the description.
|
|---|
| 28 |
|
|---|
| 29 | when the about page is produced for a collection or service cluster, a list of services are obtained, and currently their names are just displayed. We need their real names to be displayed. should this be gotten though a describe yourself message to each service and pick the name out of the display? or do a describe yourself, just for metadata and have the name returned as metadata instead?
|
|---|
| 30 |
|
|---|
| 31 | Note, describe requests have another attribute called info (I think), so you can narrow down the request eg
|
|---|
| 32 | <request type='describe' info='metadataList'>
|
|---|
| 33 |
|
|---|
| 34 | this works for the message router - is it implemented in all agents? (collections, service clusters and services?) I think it should be.
|
|---|
| 35 |
|
|---|
| 36 | ANd I think I prefer that service name eg "Query a collection" for TextQuery should be a metadata element.
|
|---|
| 37 |
|
|---|
| 38 | anyway, have a think about it.
|
|---|
| 39 |
|
|---|
| 40 | The main thing I would like out of this is for the service names eg TextQuery not to appear on the about pages, but are replaced with the metadata Title eg "Query a collection" which can then be changed depending on the users language.
|
|---|
| 41 |
|
|---|
| 42 | * add document for building
|
|---|
| 43 |
|
|---|
| 44 | The addDocument service (in GS2Construct) has not been implemented. It should take a file name and add the document to the import directory of teh collection.
|
|---|
| 45 | there are problems with just transmitting a file name - the service may live remotely and therefore the document is not there. You should probably send it attached to the html - therefore need to work out:
|
|---|
| 46 | how to get the document attached to the form (theres something to do with post and encoding = multipart ?? otherwise the browser just sends the filename),
|
|---|
| 47 | and then where to get it in the servlet - is it a parameter? or something else?
|
|---|
| 48 |
|
|---|
| 49 | and then it needs to be added into the xml request to be passed to the service.
|
|---|
| 50 |
|
|---|
| 51 | If the program is running locally its much simpler just to send a filename - can we somehow check for this?
|
|---|
| 52 |
|
|---|
| 53 | * configure Collection for building
|
|---|
| 54 |
|
|---|
| 55 | also to do with building, a little harder, is the ConfigureCollection service. There is no stub for it yet, but easy enough to add one. - need to add this service to the service description xml stuff, and write a processConfigureColleciton() method. It would be easy enough to display the config file in a big text box, and have the user edit it like the collector does.
|
|---|
| 56 |
|
|---|
| 57 | the hard bit is that when you click ConfigureCollection, you dont know what collection you are going to be dealing with - all the building services, you select the collection on the service page. with the configure stuff, you need to select the collection, and then the config file needs to be retrieved. so its really a two step process to configure the coll - first select the coll, submit that, then edit the config file, and submit that.
|
|---|
| 58 |
|
|---|
| 59 | All the services currently are one step - need to think about how this type of service fits into the model.
|
|---|
| 60 |
|
|---|
| 61 | maybe it needs a hidden arg? - to tell teh service if you're at stage 1 or 2?
|
|---|
| 62 | when teh action does the request, it then asks for the service description again to redisplay it for the user. maybe if the service knows that it has done the first half, it sends the second type of description?
|
|---|
| 63 |
|
|---|
| 64 | * sequence of services
|
|---|
| 65 |
|
|---|
| 66 | some service clusters have services that you are supposed to carry out in sequence such as building, but there may be others.
|
|---|
| 67 |
|
|---|
| 68 | can we do a generic action or xslt or something that sends teh user to teh next service once they've completed the first one?
|
|---|
| 69 |
|
|---|
| 70 | Maybe teh service cluster/serviceRack class specifies teh sequence of services, and they are all handled individually like present except that some xslt puts a next button on each page with a link to teh next service in the list.
|
|---|
| 71 |
|
|---|
| 72 | * tidy up the setup.bash, install.bash stuff. see david. theres some things that need to be done once on install, and if you do them again your system craps out. but if you change what needs to be done in cvs, the user cant update their system without great knowledge of what needs to be done. other stuff like make needs to be done after every cvs update. there are two scripts install and update which attempts to solve part of this. setup.bash needs to be run multiple times and ends up adding stuff to teh path more than once.
|
|---|
| 73 |
|
|---|
| 74 | anyway, all this install stuff could be much nicer. If you really want to make it nice, you could look at doing a proper configure, and using --prefix etc so that its a proper package (see john also for help about this) - bin, lib etc would get put to their proper places not necessarily into gsld3/bin etc.
|
|---|
| 75 |
|
|---|
| 76 | * Lucene - svetlana has done a project comparing mg, mgpp and lucene. investigate further whether lucene would be good for us to use. incremental update?
|
|---|
| 77 | report on my desk.
|
|---|
| 78 |
|
|---|
