An Overview
Gnome-Mathusalem would be a bridge between the application who want to execute some kind of job (for example, but not limited to, download, copy, send an email) and the application who can do this job.
With the Application process (AP) i mean the application who want to execute the
... [More]
job, you can suppose that's Epiphany. The AP doesn't interact directly with the interface that expose the service (it can do, but the common behaviur of the applications will not need to do it), so the AP make a request to the Mathusalem process (MP) in CLI (Command Line Interface) form by Mathusalem's dbus object. The MP dispatches the job's request to the service, each service is exposed with a dbus object that could be register on the fly or can be defined with a file in a well-know directory. MP chooses the service for each job request, by the parameters of the job, the service that doesn't expose a set of parameters that isn't a superset of the job's parameters are exclused; the job is than assigned to the first service that satisfy the request (to handle 2 or more service candidates is a problem that's not solved). The MP contacts the Service Process (SP), sending the job parameters that are provided from the application. With these parameters the SP creates a new job process (JP), which would be an effective process on the SO or not. If the creation of the new job process have success than then the dbus_path information is send to the MP which send back to the AP. In the end, if the job process is correctly created the AP will interact only with the JP for the job that have requested. AP could use the standard interface for the JP's dbus object or can use an specific interface.
Interaction between Application Process and Mathusalem's Dbus Object In the order to make this communication as simple as possible I used the CLI; every service is defined by two meta-commands, one of this (which i used to refer as commandName) is generic in the meaning that the command explain the action that will do the service, but doesn't specify which Service is under the hood. One or more Service could have the same commandName, each one can have a proper set of parameters for start the new job. The second meta-command assigned to the service is unique (i'll refer to it as uniqueCommandName), the application process can know the service behind the Mathusalem Process, and than what the job can do. Let me introducing an example, suppose that Epiphany would download a http://www.kernel.org/lastest.tar.bz2 and it would use a generic downloader. Epiphany should know that the downloads manager, usually, accept as parameters "url" and "destination". Epiphany could download the file and discard of this work with: "download --url http://www.kernel.org/lastest.tar.bz2 --destination /tmp/lastest.tar.bz2" ... or ... Epiphany could download the file, let the user interact with it (for example exposing an gui), and show a list of current downloads using: "download --request-interface org.gnome.mathusalem.user-interact,org.gnome.mathusalem.TimeConsumingJob --url http://www.kernel.org/lastest.tar.bz2 --destination /tmp/lastest.tar.bz2"
More download manager can expose the "download" commandName, they could accept the same parameters, or not. If the parameters list accepted by the services are different, then only one can be started; but if all the services accept "url" and "destination" as parameters, Mathusalem will choose the service that will do the job (by user settings for example or other method). Suppose, now, that Epiphany expose a self-made download manager and want to use it because "is the best download manager never-made", if the download manager of epiphany have "download-with-epiphany" as uniqueCommandName, epiphany should use this command: "download-with-epiphany --url http://www.kernel.org/lastest.tar.bz2 --destination /tmp/lastest.tar.bz2"
In the future, if syntax analyzer will support constructs like IF FOR..., the services like "notify" or "rename" could have some sense:
IF [ download --url http://www.kernel.org/lastest.tar.bz2 --destination /tmp/lastest.tar.bz2 --output out; ] THEN
notify --text "Download of $out[url] is completed" --button1 Open --command1 "open --url $out[destination]" --button2 "Open Folder" --button2 "open-folder --url $out[destination]";
ELSE
notify --text "Download of $out[url] is failed\nError: $out[errorMessage]" --button1 Retry --command1 "restart" --button2 "Cancel" --command2 "nop";
FIthe previus code is only an idea! With the previus commands epiphany could forget that have started a download for "http://www.kernel.org/lastest.tar.bz2", Mathusalem knows what should do if the download fails or if it have success, of course supposing that exist an SP that accepts "notify" as meta-command and that accepts these parameters.
Introducing Mathusalem Interfaces Every job have at least one interface exposed by DBus, this interface allows applications to comunicate with the job. If the job exposes an interface that the application knows, then the interaction between application and job process could be very simple and intuitive. On the previus example, I supposed that "epiphany" need to download "http://www.kernel.org/lastest.tar.bz2"; as user, I expect to see a window where i can control the download process, and where I can interact with it. Suppose that Epiphany knows this interface:
/*this interface is only an example*/
public interface DownloadJobIface: GLib.Object {
public abstract bool supportMultipleDownload();
public abstract void addSource(string s);
public abstract string[] listOfSources();
public abstract void removeSource(string s);
public abstract int getProgress();
public abstract int getTimeRemain();
}Epiphany, with these information, could to show an appropriate graphic interface with which the user can interact; the graphic interface could to interact directly with the job process using the DownloadJobIface interface.
Another intersting aspect of the interfaces is the ability to collect similar jobs. Supposing that Epiphany would display ALL the download jobs actually on the system, one way to do it could be let the service process to comunicate with epiphany process with a direct-line ... obviously this way could work only if the service process and epiphany process knows exactly who they are and what's the protocol used to comunicate. Instead Mathusalem exposes an object like the java.listener, the listener are created using the name of the interfaces that each job exposes. The listener could be requested to Mathusalem Process which will look for all the job that implements the interface specified, which will advise the application process when a job with the requested interface is started or is terminated or is crashed. In this way Epiphany could know all the download processes, even the download processes started with some other "download services", using the JobIface could know which of these are started with the own download service and which with other download services.
The Interface's listener could be used in more other contexts: nautilus could monitor all the processes that write on the disk showing a progressBar near the icon of the file that is the subject of the writing, pidgin could monitor all the file sended with msn protocol ... doesn't matter who have started the requested (could be pidgin itself, or nautilus, or evolution, or
), and finally the listiner could be used to monitor the "Time consuming" jobs, if all the jobs that require lot of time to be completed expose the interface:
/*the proposed interface for the time consuming jobs*/
public interface TimeConsumingJobIface: GLib.Object {
public abstract bool getCapability(uint32 action);
/* or this?
public abstract bool canBePaused();
public abstract bool canBeStopped();
*/
public abstract uint32 getStatus();
/* or this?
public abstract bool isPaused();
public abstract bool isStopped();
*/
public abstract bool start();
public abstract bool pause();
public abstract bool stop();
public signal void onProgressChanged();
public signal void onStatusChanged();
public abstract double getProgress();
public abstract uint64 getEstimatedTimeRemain();
}the example-application that i wrote show all these jobs (the time consuming jobs) in a single window.
TODO's - Define a policy for choose which is the best service that satisfy a command line where 2 or more services have the requested parameters. - Auto register and unregister for service process: some service process could be described in a well-knowed directory, if the application that expose the service process is crashed, Mathusalem process should stop to receive every request for this service - Ehnanche the CLI, with the support of construct like IF;FOR defining a way that allow the job process to say which is the output values
How To Try do the svn checkout cd gnome-mathusalem ./autogen make cd job-monitor ./autogen make cd ../download-service ./compile
Now you have the complete environment (i hope :)). If you want try Mathusalem (and probabily you want that if your are reading this :D ), you must follow these instructions in this order: cd ../gnome-mathusalem ./Mathusalem & download-service/gwget-service & job-monitor/job-monitor &
now, using the dbus-bin-tools: dbus-send --session --type=method_call --print-reply --dest=org.gnome.Mathusalem /org/gnome/Mathusalem/Services org.gnome.Mathusalem.ServiceManager.startJob string:"download --url http://127.0.0.1/data --filename /tmp/foobar"
Thanks for your attenction, I'm waiting for your opinions. [Less]
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.