sysnotdown 发表于 2006-9-30 15:53:31

MultiGet调整征求意见！

感谢大家关心和使用MultiGet。

做这个MultiGet我化了将近两个月的时间，现在是0.7.1版。最初只是出于学习的目的，后来我发现它也许对大家有点用处就发布出来了。但是因为从练习出发，设计就很不完善，虽然修修补补也能把功能做全面，但是代码可维护性太差，功能越多麻烦就越多，程序就越不稳定。
Linux下有许多下载器，各有其长，但都不能算完善。而现在我想做的是一个完善好用、功能全面的下载器。包括多址传送，ftp,http, ftps,https,rtsp,mms,甚至rsync等协议的支持，在现有的设计下复杂度很高很难完成，而且我自己也没有精力来写全rtsp和 mms。
要做到这些几乎必然要采用模块化设计，可以变插件的都要变插件，然后一个个地稳定、合成、测试。系统架构和ftp,http两个基础件我可以做完，其他的协议支持插件可以让有兴趣的人来开发，也方便大家合作。这样的话我就要停止现有代码的升级，因为我知道下一代的开发结构一定会有大改，现在的代码很难在以后能用的上，可能是无用功。

所以问题就来了，我是不是要停止现在的代码重头来过？时间太紧，我需要在年底前完工。实际上现在的版本已经够我用了，剩下的代码对我没有太大意义，完全是细节。我个人倾向于停止现在版本的升级，重头来过，你们看呢？

WeiMingzhi 发表于 2006-10-1 12:27:56

sysnotdown 发表于 2006-10-2 20:28:28

这个问题不是大问题，用静态连接的程序就可以，依赖也少，不过0.8以后我会测试一下unicode的编译，尽量兼容unicode编译。

steeven 发表于 2006-10-9 11:10:12

ftp/http可以满足大部分需求，其它协议优先级不高。
p2sp希望优先考虑，这决定下载能否成功，并且极大的提高速度。建议利用迅雷的资源。

sysnotdown 发表于 2006-10-9 11:48:29

ftp/http可以满足大部分需求，其它协议优先级不高。
p2sp希望优先考虑，这决定下载能否成功，并且极大的提高速度。建议利用迅雷的资源。

原不计划加的，不过0.8已经有一个不带搜索的多址下载了。
页: [1]
查看完整版本: MultiGet调整征求意见！