[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microdc-devel] features for microdc
From: |
Hasan Khalil |
Subject: |
Re: [microdc-devel] features for microdc |
Date: |
Tue, 18 Oct 2005 12:42:43 -0400 |
On Oct 18, 2005, at 06:32, Oskar Liljeblad wrote:
0.11.0 will be released later today.
Sweet!
Meanwhile here's a question for
everyone of you:
What new features do you think would be most important for microdc?
What would you like to see implemented the most?
* Graphical user interface based on GTK/Gnome or KDE/Qt or curses?
Why not? There are already other good GUI DC-clients for POSIX
systems.
I completely agree with the 'why not' here. The main reason I use and
love microdc is that it is CLI, and diverting development resources
to something that's already been beaten to death seems a bit useless
to me.
* Multiple hub connections
Why not? It's easy to run two concurrent versions of microdc.
This would be great, especially given that running two concurrent
instances of microdc does not allow for sharing n download slots
amongst m hubs freely. (feel free to ask for clarification if that
was ambiguous)
* File hashing support
Why not? What's the benefit - better searching I guess?
Since this more-or-less seems to be a 'safe' way to find exact
duplicates, I would say it's a Good Thing™ to have implemented, just
for completeness.
* Retrying downloads and reconnecting to users
Definitely not a gripe of mine, since I personally only use microdc
as a server share and not a client share.
* Better platform compatibility (please specify platform/system)
I run microdc on my Linux (2.6) server without any problems. Should
you need someone to test on a Mac (OS 10.4), I can do that for you,
but I haven't done so (or had the need to do so) yet.
* Caching and automatic update of your own shared file list
This would be really great, and would probably be easy to implement.
I would personally start here -- pick the low-hanging fruit first.
* Bzip2 and XML file lists as supported by DC++
Apart from saving some bandwidth with bzip2, what would this gain?
Also, is it to spec with the 'official' protocol? Do we care? Please
pardon my ignorance.
* Move all code to CVS
Yes, please! I'd love to see the latest development, and maybe even
contribute a few patches myself when that mythical 'free time' thing
rolls around.
* Prereleases announced on this forum, more often, for bug testing
Probably good for QA, but I wouldn't kill myself over it just yet.
Personally, I'd let the user base expand a little bit before going in
this direction.
I hope this helps.
-Hasan
PGP.sig
Description: This is a digitally signed message part