[CWB] Direction of development of CQPweb

[Hardie, Andrew]

Hi all,

 

This email is to initiate a consultation about two aspects of the
development of CQPweb as it moves towards the long-planned next big
version. 

 

(So list members who have no interest in CQPweb should feel free to stop
reading now.)

 

These two things represent changes to the design policies I have been
following so far, which is why I would welcome the input of people who
are using CQPweb, whether as a standalone on their own machines, or as
adminstrators of a public or semi-public server. (Of course, anyone not
currently using CQPweb right now but who might want to do so in the
future is also very welcome to chip in).

 

Each big change has a range of advantages (which is why I want to do
it), but also one possibly-show-stopping disadvantage.

 

The first big thing is that I want to change away from the current
system of user login management, where it is assumed that the web server
itself will manage access (with some limited support tools that work
only with Apache), and instead use session cookies and manage the whole
thing within CQPweb.

 

Advantages:

 

*        The logon system would no longer be Apache-specific (indeed, it
would be possible to scrape out ALL the Apache-specific code)

*        On Apache, it will no longer be necessary to rely on htaccess
files, which can slow down the response time

*        It will be a more solid platform for building an interface to
user-centred functions, e.g. automated account creation, personal saved
CQP macros, and so on.

*        It will be possible to manage different levels of access to a
single corpus (currently it's all or nothing)

*        It will be much easier to have "open" CQPweb systems, i.e.
systems where someone who is not logged in can use the corpora, but not
the admin interface; this is currently very fraught, but I'm aware it is
something quite a few people want to do

*        It will be possible EITHER to have a reasonably secure password
system OR to allow users to retrieve forgotten passwords via email (I am
tending towards the former)

 

Disadvantage:

 

*        CQPweb would no longer work if the user's browser won't accept
the session cookie.

 

Secondly, I would like to add more extensive use of JavaScript doodads
into the user interface (NB I am not contemplating any Ajax [ie
communication with the server taking place in the background], at least
not in the foreseeable future). There are currently a couple such
doodads, most notably the colourful tooltips, but nothing that means
Javascript is required for the tool to work, as I have up till now been
specifically avoiding anything of this nature.

 

Advantages:

 

*        One of the big problems that CQPweb faces is balancing (a)
adding new features against (b) keeping user-interface compatability
with BNCweb (and, increasingly, its own earlier versions). If I can use
Javascript to "hide away" links to new features within folding-out
doodads in the current interface, this becomes much easier.

*        Generally it becomes possible for the interface to behave in a
much slicker way.

 

 Disadvantages:

 

*         CQPweb no longer works in browsers that have JavaScript turned
off.

*        Icreased potential for browser-incompatability bugs, especially
with Internet Explorer (I develop in Chromium); however, fixing these is
not usually too hard once they are spotted.

 

My perception is that nowadays, it is not unreasonable for a complex web
application to require both cookies and JavaScript. Cf Gmail, facebook,
much online banking, inter alia. However, that is why I am asking on the
list before starting any of this - would either of these requirements be
a major problem, or even a deal-breaker, for any current user of CQPweb?

 

Comments on this, or on any aspect of the above, are very welcome.

 

best

 

Andrew.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://liste.sslmit.unibo.it/pipermail/cwb/attachments/20110515/0e1e5f01/attachment.htm