I just committed some code to add DBus capabilities to GGet. I came up with the following interface:
Methods:
AddDownload(String uri, String path) -> String id
CancelDownload(String id) -> Boolean
GetDownloadInformation(String id) -> Dict of {String, String}
Hide()
ListDownloads() -> Array of [String id]
PauseDownload(String id) -> Boolean
Present()
Quit()
RemoveCompletedDownloads()
RemoveDownload(String id) -> Boolean
ResumeDownload(String id) -> Boolean
Signals:
DownloadAdded(String id)
DownloadRemoved(String id)
DownloadStatusChanged(String id, String status)
Does this look sane? I was thinking about adding a signal for bitrate changes aswell but I’m afraid it could could be something of a performance hog since it would emit changes constantly. Someone suggested that I could implement a publish/subscribe system to make sure I only emit the signal when there is actually someone listening. I think this will have to wait until if/when its really needed though.
The plan for the coming days is to continue to fix bugs (there are still plenty) and to start working on a Epiphany extension which will use DBus to talk to GGet.
If it doesn’t already get this from epiphany, it would probably be a good idea to give it some sort of mechanism for passing referrer URLs and cookies. Otherwise a fair sized chunk of downloads won’t work 🙁
Please don’t use any handle mechanism instead create object for each download, something like this:
[interface ???.DownloadManager]
Methods:
– AddDownload(String uri, String path) -> Download Object Path (generate the path based on the uri)
– RemoveDonwload(String obj_path) -> Void (return an error if it fails, it should automatically cancel the download if not completed yet)
– ListDownloads() -> Array of [Object paths]
Signals:
– DownloadAdded(String obj_path)
– DownloadRemoved(String obj_path)
[interface ???.Download]
Methods:
– GetProperties() -> dict of {String, Variant} (or even better use dbus interface for properties)
– Pause() -> Void (return an error if it fail)
– Resume() -> Void (return an error if it fail)
– Cancel() -> Void (return an error if it fail, do not destroy the object instead give it a status cancelated so one can call Resume and restart the download)
Signals:
– PropertyChanged(String propname, Variant propvalue) (again dbus properties interface might be a good option here)
Another advice is not going with gobject+dbus-glib to develop the daemon, it is too much for too little, libgdbus should be enough (see obex-data-server X obexd).
David has a good point.
Another idea, which is probably beyond the scope of your GSoC work on the project, could be some of means of controlling the download (i.e. which portions of the file to download) as to allowing ‘streaming’. E.g. PDF have specific provisions to allow the reader to retrieve only the parts of a document which the user scrolls to. I’m not familiar with the exact provisions, but it would be neat if e.g. Evince would open immediately when a PDF download is added to GGet and fetch only the necessary bits of the document through the GGet API.
Vudentz: Ah, that is much nicer indeed, thanks! One question though, what do you mean with “return an error if fail”, print something? Any reason not to use a Boolean there?
As for epiphany, you’ll find some limitations due to gecko, I think the best bet you can do is to hack the download manager of epiphany to hook to gget if it’s available/configured.
For example:
– click on a link
– “where do you want to save this?”
+ hook here and check if “Use gget to manage downloads” is checked in ephy config, if it is then run gget, otherwise just continue the normal code.
The trick would be with cookies and sessions, some downloads won’t work I think, I’m not really sure if you can fix that somehow. For example, the online-desktop uses firefox’s cookies, I think they have a mini python service for that, I can’t recall where it is though, but it’s a python script of like 100 lines, quite a hack. You could use it or take the idea from there.
Let me know when you want to start integrating with ephy and will try to sort out something, you are doing great work so far! 🙂
Referer and Cookies should not be that hard to pass along as (optional) extra parameters, it’s a String and a Dict of String,String, and they can be empty if there is no need for them or the app doesn’t have them. Or you could add extra methods.
However, maybe it’s a good idea to be a bit more generic? Some sites need User-Agent (because they suck) and there’s authorization, and more, so instead of Referer, it should probably be a dict of HTTP headers. That would also take care of cookies on the way.
Oh, and can you deal with POST? Or where is it that you think you want to inject your application in the chain? Will there be double calls somehow or how is it decided that the manager should take over?
I wonder if the best thing still would not be to allow apps to update common task bars instead, that’s the real killer, not that it downloads things… that could on the other hand be a great library? Common download lib?
Ah well, time will tell. 🙂
johans: I meant return a dbus error message with a useful message why it failed, there is no need to return a boolean if you don’t give a reason.
For some more ideas, google for the (ill-fated) Mathusalem project, from SoC a few years back.