openDias - Get Involved

Help the project

There are lots of ways to help the openDias project:

• See the 'Urgent Help Required' list below.
• Checkout, build, test, package and feedback from the current development head.
• Submit and Vote on Ideas and Suggestions..
• Publicise the application, to get as many people using/testing/talking about it as possible.
• Submit patches at GitHub Source Repository, or request to work on one of the TODO items.
• Make a donation via PayPal, to help towards the cost of hardware for testing.
• Click through on one of the adverts displayed on this website, this helps to support hosting costs.

Urgent Help Required

The project requires urgent help in the following areas. If you can help, please get in touch via the forum or drop us an email.

• We are looking for help to get our distro package builds up to an acceptable quality for inclusion into Debian, Ubuntu and Fedora repositories. Any help in updating packaging systems or getting picked up for repo inclusion would be much appreciated.
• We need assistance in translating the application into the following languages:
  • French
  • Spanish
  • Chinese
  • Others, always very welcomed.

Developer Resources

The application road-map can be seen here.

Developers can interface into openDias using the published API to build alternative (eg android app) or enhanced frontend (eg batch input) interfaces, or as a reference when developing on the backend.

Technical Architecture Overview

Backend

The application is written in C with a little C++ to handle some libraries, and is multi threaded. Each of the child thread handles HTTP request from clients (users). The parent thread is reserved to process SANE requests (sane cannot be multi threaded), by opening a local port that will queue SANE command requests from one of the HTTP handling threads.

The application uses SQLITE 3 to store, system configuration, user configuration and document details. Media files (scanned images and imported docs) are stored as individual files on the filesystem. All session and accounting information is held in memory and not retained between restarts.

When a client makes a request, one of the child threads handles it. It's HTTP contents is parsed and the data validated before it's dispatched to a method specifically written for each of the API calls. The method will construct the response that eventually gets passed back to the client.

If the HTTP request is going to be a long running process, ie a scanning operation, a new thread is created (parented by the client thread) which will actually handle the processing of the request. The parenting thread (the client thread) simply responds with a reference that can be used in followup API calls (to check progress).

If a method needs SANE functionality, a command request is built and sent to the application parents thread port, who processes the SANE request and replies to the calling thread with details of what happened. It's then left to that processing module to handle any errors appropriately.

Frontend

The UI is essentially just a few static HTML files. These files load Javascript (usually JQuery) that make AJAX requests to the backend to query for information (eg document details or list of currently available scanners) or trigger actions (make a new scan, update details or import documents).

As long as proper API calls are made, a completely different frontend could be used in place of the bundled GUI.