[OPEN-ILS-DEV] ***SPAM*** Re: ***SPAM*** Rethinking the Evergreen OPAC client

[steven chan]

On 3-Nov-09, at 3:18 PM, Jason Etheridge wrote:

> Let us know if there are API tweaks or additions that could make  
> things easier. I've
> always had a wish for multiple OPAC's and staff clients competing and
> cooperating, using the same API's, but different technology stacks.

Hi Jason. Generally speaking, if the API was more completely  
documented and in more detail, I would guess there would be one less  
barrier to development. I think one of the strengths of the Evergreen  
system is its rich ajax API, but I also thinks it needs a bit of an  
architectural review.

In terms of specific tweaks, I have described them in an internal  
design note of mine, which I copy and paste below. On the input side:

Automatically package input data consisting of multiple values into a  
list. Provide sensible default values for some service calls that  
offer more general services than that needed by the OPAC. Combine the  
two-phase login sequence consisting of ‘auth.authenticate.init’ and  
‘auth.authenticate.complete’ into one service call  
‘auth.session.create’ and persist the returned session ID for future  
use. For services accessing user records and circulation transactions,  
which require the caller to use a session ID, automatically provide it  
if there is an active session. For those services requiring a user ID  
as well, provide it automatically if the caller does not specify one.  
Shorten the service name from, for example,
service=‘open_ils.search’, method=’open- 
ils.search.biblio.multiclass.query’
to ‘search.biblio.multiclass.query’, because the prefix is common and  
we assume a service call will not specify the method of another service.

On the output side:

If output data is a list of anonymous values, automatically convert it  
into an object. If necessary, recurse into nested lists and return  
nested data objects, ie, do 'field-mapping'. Convert any other output  
data values into sensible data objects.

> The support side of me would be a little worried, but the freedom of
> choice it would bring would just rock.  And I still want a
> ncurses/text interface other than srfsh, darn it. :D


Perhaps we should start a new thread of discussion about a text  
interface. I have done some thinking on this, but would like to hear  
from you about the whys and hows.

-- 
steven
BC Evergreen Sitka project
schan at sitka.bclibraries.ca