Averti: Plans for the Future

The purpose of this document is pretty much to lay on paper many of the ideas that have been jostling through my head during the past two months. I haven't touched Averti in that time, but have thought about it and this is the result of all of that. This document will probably venture back and forth between too high level and tmi, but -- well . . . too bad. Many of the features that I will speak about are in fact supported by the demo version of gTask, though probably not implemented in the correct way. So this document will eventually become the place to look to for status information on the individual parts of the project. That being said -- here's my grand plan for the future:

Project in General

  1. Averti should not be something that is gnome specific. In fact, if it is to be successful it needs to be something that can be accepted by all of the major desktops.
  2. The library will be split into two parts. One will handle all the background processing and the creation of tasks and the like. The other will handle the graphical user interface elements. The project will also contain two other programs, one an implementation of a task tracking daemon, the other a panel applet for viewing the tasks that the daemon is keeping track of.

"Basic" Overview

  1. Tasks: All task metadata will be stored in RDF. This gives us the benefit of having an easily extensible structure for storing this metadata that others can arbitrarily extend without affecting the core library in the least. Our initial targets for integration are epiphany and sound-juicer, so the gnome platform bindings will most likely include task classes that have been customized for those programs. Below are the pieces of information that the can be stored (as in there will be a corresponding rdf schema for it) for a task.
    Basic Task
    Activity State Active|Inactive|Completed|Error|Stopped
    Title the title of the task
    Thumbnail URI The uri of an image that should be used as a thumbnail for the task
    Status Message some status message for the state of the task
    Error Message a message that can be set if an error has occurred
    Application the application that is controlling the task (this will probably be a uri)
    Percent Done the percentage of completion
    Time Started the time the task began at
    Time Completed the time the task was completed
    Time Remaining an estimate of the amount of time until the task will be completed
    Sub Tasks any number of sub tasks that comprise this main task
    Category The user interface category that this task should be placed into
    Extensions for a File Creation Task
    Source This will be where the file came from. It will be a uri and could indicate a file on the filesystem, or perhaps some program that created it, or even a link to a person that sent the file (ie over IM)
    Destination This is the uri of the file that was created
    Bytes Written The number of bytes that have been written to the destination file
    Bytes Total The number of bytes the destination file is expected to be upon completion
    Write Rate The rate at which bytes are being written to the destination file

    The client library will include wrapper objects around these task types that will make it realitively painless to set the most used properties on them and alter the daemon of the changes. The client libraries can also be used to create task types that would not actually be modelled as a new RDF task class. A good instance of this is the DownloadTask. In essence the DownloadTask is just a FileCreationTask that is being performed by a web browser. There is some additional information, however, that we might wish to associate with the file, such as the page the file was downloaded from and the title of that page. The client library can provide a class that handles the creation of these resources and links them with the destination file automatically.
  2. Commands: All tasks have a notion of actions that can be performed on them. By default it is not assumed that any given task registered wit the system supports given actions. In practice though, each class of tasks is expected to support a particular range of operations. As an example a download-task should support the stop, pause, and resume actions. When registering a new task with the system the program that is ultimately managing the task should specify which if these actions that particular task supports. The system should also allow for some actions to be subclasses of other actions. So, for example, a user might wish to tell sound-juicer to either stop all operations, or simply stop the ripping operation and continue encoding what is has.
  3. Queries: Users should be able to perform arbitrary queries against the task daemon's database.

Desktop Integration

  1. The system should offer a number of points for possible integration into various parst of the desktop. Since our initial bindings will focus on gnome, the next few suggestions will obviously be gnome-specific.
  2. Nautilus: there was a suggestion on the nautilus list to have nautilus be able to reconize files that were being downloaded, etc and perhaps display a piece of progress information on the icon itself. Safari does something similar to this. This could be possible by setting a special emblem on the file, which nautilus could use to contact the task daemon and ask for updates on the status of the file. Nautilus could then display its' own progress information
  3. Beagle: The task daemon could have a plugins system that would allow beagle to be notified when a file had been completed so it would be able to add it to its' index