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.

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!

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.

[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).