Quick D-Bus Overview:

D-Bus objects and interfaces
    Objects:
        Core: supports the Core and Task interfaces
            The task interface is generally just used to push updates
            on tasks to the core objects

        Daemon: supports the Daemon and Task interfaces
            The daemon interface handles the registration of new clients and tasks
            The task interface handles the updation of tasks, executing commands on them, retrieving task info, etc.


Current Issues:
    Task subclassing:

    There is the issue of how to handle subclassing. It would be nice to have programmatic wrappers around this sort of thing, but rdf allows us to be way more flexible than might actually be useful in the general case. Currently new tasks are created from an AvertiCore object. The design was that you would specify the type of task you wished to create by the uri of it's class. You would get an AvertiTask back, that was an actual GObject and had methods defined for setting/getting the basic properties. My intent was to support subclasses, not through the GObject and GType systems, but rather to allow people to simply drop schemas in a directort, or register them with the system and on startup the library could read this information in and construct it's own class heirarchy. We could then support subclassing by asserting all of the rdf:type relations that apply to a particular instance and having sets of convenience functions to actually allow people to set/get these properties using native data types. I was thinking about creating a set of generic rdf getters/setters for various xml-schema datatypes, or perhaps even allow people to extend the system using custom objects and GParamSpecs in some way.


    Serializing rdf:

    Over the lifetime of a tasks' execution I doubt that a great deal of the data will change much, so it would be nice to reduce traffic across the bus by only sending those statements that actually need to changed.

    Also, currently the system only sends a shallow copy of the object. All statements with the task's uri as the subject are sent over, nothing else. This presents an issue in that we would like to be able to more richly describe tasks in the future, in which case blank nodes, etc are very useful. So there are 2 main issues here 1) how to decide which statements are particularly relevant to a task (ie, should be sent across the wire), 2) how to ensure that all blank nodes that are created are unique across the system (between the daemon and all it's clients for essentially all time) There are a number of ways to solve these issues. I believe the first can be solved easily enough by associating all statement for a particular task with a redland context, that way, if you assert it through the task's public interface, you should be good to go, since we can always grab only statements asserted in that context when we are serializing. As for 2, I aside from generating uid/gid's (which I have to look into) or possibly using tag uri's (which could work -- locally if we have all programs give us a uri-space that they control) we can do something similar to the current set up in which clients ask the daemon to allocate and return to them a new blank node, but that seems sub-ideal, so I'd rather it not have to be that way.

    General Cleanup:

    Many items, not just tasks may store themselves in rdf, so I would like to create a simple base AvertiRdfResource class that can automatically clean up after itself when it is destroyed. No biggie, just really simplifies the management of the store.

Querying the Server and Pushing Updates

    Currently updates are specified on a core by core basis which means you can simply pick and choose tasks to watch as they come, you get sent all the data all the time. Once again, fairly easy to fix, but really not a high priority right now.

Reacquisition of tasks:

    There are a number of issues that stem from the fact that programs may crash or the user may close it, thus stopping the task, etc. There's also the distinct possibility that the daemon itself may crash. Right now the daemon simply passes data through and does no real checking on it at all. This will not be the case in the future though. The daemon should not allow one program to update another program's task info, etc. At this point it becomes necessary to have some protocol for taking back control of a dormant task.

Performing Actions on Tasks:
    This is pretty well summarized in the html file.

Metadata about the programs running the tasks

Allowing plugins the extend the user interface
    The system should support basic tasks by default. Anything more exotic than that should probably be handled by a plugin. For instane, when you are downloading a file, there really is no status message per-see. It is generally a summary of how much of the file you have downloaded and how fast you are downloading it. It makes much more sense to represent this task as having that information and no status message and then just have a plugin that is smart enough to say, hey -- if there is no status information then I'll display this amalgamated data.

    Plugins should also be able to extend the context menus, add arbitrary actions, and eventually provide their own cell renderers. For the moment I think it would be best to allow them to provide override the default fill-ins in the current cell renderer. I plan to also allow them to make requests to thumbnail images, etc and then have those requests dispatched to another thread for execution, that way the ui won't block as it did previously.