[sword-devel] Web Interface - Customization

Chris Little sword-devel@crosswire.org
Fri, 28 Feb 2003 16:19:24 -0700 (MST)

On Sat, 1 Mar 2003, Rev. Michael Paul Johnson wrote:

> >What diatheke currently does (and what would be my recommendation) is just 
> >set cookies on the client.  Nothing is required of the server maintainer.  
> >If people disable cookies, the have to live without these features.  The 
> >only real drawback is that it doesn't work if you switch computers or do 
> >most of your work from different (e.g. public) computers.
> If it is quick & easy to change preference settings, this isn't a major
> problem.

There are potentially a lot of preferences to set & save, h means it can't 
be quick & easy.  At the very least it is an inconvenience that we should 
attempt to avoid imposing on users.

> >A third possiblity, if we want to deal with it, might be to set up a 
> >single central preferences database, hosted by CrossWire.  This relieves 
> >3rd party server admins of the need to set up the database and provides 
> >the added bonus that, regardless of which server or which client you use, 
> >your server will always request and receive the same settings from 
> >CrossWire's server.  We can set it up as a web service that the 3rd party 
> >servers could query.
> This is bad for scalability and fault tolerance. It would be better if
> all other sites using the same engine kept running with no degradation
> in service even if CrossWire's server were to go down for any reason.

Nonetheless, a central database is the only reasonable way to store the 
data long-term in a way that minimizes the difficulty of running a site.  
Some hosting services may provide DBMS to their users, but most do not.  
And we probably don't want to deal with connecting to different databases 
that might be provided by different hosting services.  A single XML-RPC 
or similar call to CrossWire in order to retrieve settings won't be that 
expensive as part of the login process.  And it exists as the only way I 
know of to allow different hosts to share settings (unless there has been 
some laxing of cookie security lately).

That data should ALSO be stored in a cookie on the client side.  When that 
fails (e.g. because a public computer is being used or the user just wiped 
his cookies) a login may be supplied to the host, when passes this on to 
CrossWire to request the settings (that are then stored in a cookie again 
on the user machine as well as retained by the host for the duration of 
the session).  If CrossWire is down, oh well.  It's not a life & death 
situation if you can't turn of verse numbers or set your favorite default