Re: [gnome-network]Download manager

Rodrigo Moya wrote:
- having multiple projects so you can categorize your downloads
	- speed limit per project
	- default directory per project
	- max simultaneous downloads per project
hmm, projects? I don't see the point of this, so please explain :-)

Instead of having all the downloads in the same list, you can have different lists. Each list is called a "project" and has its own settings. For example, I have the Gnome List/project, downloads added to that project always go to the garnome cache directory, it has a limit of 1 simultaneous download and a speed limit of 10Kb/s. I don't have to redefine this for each download. I have a Windows project that saves the downloads in the windows partition, this is great when I download gaim for windows.

Also, the idea of project will help in getting a "recursive download project", a special tree-like list to download websites, ftp directories and so on.

For the upload part (still not implemented in downman), you will be able to drop files in a tree-like view of the remote site, just like you will do in nautilus but with an "upload manager". But I'm not sure what uses upload has, since nautilus already does this.

About _inclusion_ in gnome-network, I'm not sure at the moment, downman is coming big and I would like someone to develop a KDE client. About gnome-network _integration_, for sure :)

well, if it's not included in gnome-network, then, how do you do that

Following a "download manager IDL" for example. But anyway, gnome-network won't have any dependencies, will it? And I can always do a separated release if needed (including a KDE client). And for the gnome-vfs side, I will play with implementing download backends so the gnome-network version can be gnome-vfs enabled, and it will help if we ever get gnome-vfs to be gvfs.

I have also talked to epiphany developers about downman integration and we finally come to the conclusion that the better thing to do is write a plugin for epiphany that will hook to the "unhandled mime-type signal". I have started moving the "new-url" dialog to a bonobo object so that it can be used from other apps, and by gdownman itself instead of the hardcoded one. Also downman-gmonitor, the "basket" to drop urls will make use of it, this way more code is shared.

Anyway, if you want to really start another project, define some IDL so programs can operate with different download managers seamlessly.

yes, this could make a lot of sense. We don't really want to start a new
project, and that's why we were looking at emphetamine. But what we want
is to have a download manager in gnome-network. This is something that
must be in the core desktop, and since gnome-network will be included in
GNOME core for 2.6, we need to have it.

I read this on the emphetamine mail:

"... I have been planning on rewriting it from
scratch to use a separate daemon backend and gui frontend code, so that
it can be integrated better into the desktop as *the* download manager ..."

Downman has been built around the daemon/GUI separation already, this is what attracted me of darxite in the old days.

I don't think there is need to put a download manager _inside_ gnome-network. The core release also needs a simple text editor, but gedit is packaged standalone. What benefits will result from packaging downman inside gnome-network? I mean, apart from being in gnome-cvs and getting translations, which can be done as a standalone module.

I've CC'ed Rodney, who is emphetamine developer, and who is doing some
refactoring code on emphetamine before including it in gnome-network. I
guess we can come to a shared solution.

I have tried to talk to Rodney, but he doesn't seem very kind to discuss. I have just got a "don't bother me" when trying to talk to him.

But really, gnome-network needs a download manager. Which reminds me
that we don't only need a download manager, but a transfer manager,
since, as Rodney told me yesterday on IRC, we also want to allow users
to upload files, or to make copies of files between remote machines.

Well, the upload part is not very hard. What involves more work is implementing features, since you have to code it in the daemon, do the command/communication part for the client and the GUI in the client. Upload is just one more feature, since speedlimit, simultaneous downloads and other porperties will also apply to uploads.

I agree with you with having a download manager in 2.6 or whatever. If you really think that it is better to package it inside gnome-network, I have no objections and I will be very happy to cooperate. Just decide what one is going inside gnome-network, since we don't need two download managers in the same package :)

See you.

Manuel Clos
llanero eresmas net

TCPA y Palladium:
TCPA and Palladium:

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]