Sunday 17 October 2010

Still going

Just a quick note to say, I'm still going with this. Lots of scope creep and much re-designs/re-works. But the end is in sight.

Saturday 22 May 2010

... and relax

OK, that was even easier than I thought!
The application is now migrated and looking very nice! (well a lot better than the client based app).
Along the way, I've thought of a number of things I want/need to do, that was not listed in the brief analysis.

  1. Add security access layers; so that user or locations get abilities to: view/add/modify/etc..... docs
  2. Make server requests follow a common API, so that someone else can implement a frontend.
  3. Addition/migration of the regression testing

I'm gonna have a bash at these now.

Wednesday 12 May 2010

A change is as good as a rest

So, after a review of the architecture and some experimentations, it was decided that a desktop app was not cutting the mustard. The only options to fulfill all the needs, and make for a better user experience was: a web-app.
  • A server application that interfaced to the database, connected to scanning devices (via sane or sane-net) and provides a soap based communication interface for querying and manipulating the data/  triggering events (scans).
  • Then, a simple set of HTML pages with a rich layer of Javascript over the top. This web interface, will send AJAX calls to the backend and update/present the data as required.
The experiments will be merged into HEAD.

Tuesday 13 April 2010

The big move to the web

It's become clear that a client application does not fulfill the requirements fully. Were missing the ability for several users to participate in the document store. The solution is simple, move to a client/server architecture.
At first glance this sounds a large undertaking, and in many ways it is. The benefits however ready do justify it. In terms of implementation there are three elements:

  1. Move client functionality from GTK onto a web frontend, most probably static pages with AJAX driven content.
  2. Add a webserver to the main body of the application.
  3. Migrate the 'glue' that runs the app, from one mechanism to the other.

So, with no major barriers, lets go....