[讨论]关于开发一个下载工具

sjinny

2004年11月29日，开始和dalin、寂寞空山语、蓝爷爷（是他自封的 ）等在公社的qq群里讨论写一个新的下载软件的事，现在陆续把一些整理后的讨论记录贴了上来，一是做个记录，二也是想在论坛里和大家讨论，不过那个帖子专门用来贴讨论记录，所以请大家到这个帖子里来讨论~
记录帖的链接：
http://www.linuxfans.org/nuke/modules.php?name=Forums&file=viewtopic&t=95696&start=0&postdays=0&postorder=asc&highlight=

yunfan

看到这个个，很感兴趣.
随便谈一点个人的有关体会和看法。

1. 我个人经验, 程序的总体设计太重要， 如果设计上有问题，这个东西，
到后来肯定是没法做了。
尤其是要支持plugin的。我个人认为， 在设计上要看得远， 你上面提得已经挺远得 了：)， 但是在开始开发时，还是在一些地方，可以作一些暂时处理
(以后也很容易更改，因为设计方向是对得)，以实现或者测试开发的功能，
然后一步一步地走下去。

2. 参考一个现成的项目， 可以少走很多弯路， 这是开源的好处

3. 数据结构和用户界面是一定要分离开的，(对于kde而言，如果用户界面统一于一个class的话，可以很容易做成kpart集成进konqueror, 我只了解一点kde的情况，其它的不懂)

4. 另外，人员上应该分工明确， 主要人员(重点在做程序宏观上的设计， 人不要多)，
一般开发人员(十分感兴趣的新手或者经验不足者)等等。

5. 个人认为，最好发到一般开发人员手中的是具体的class和公共接口，
再由他们反馈意见。就是在开发的人员组织上，做到“民主”和“集中”的结合，
但我个人认为， 目前“集中”多一点也许不是坏事

谈了一点拙见,大家见笑。

sjinny

呵呵~
1.这些是我们讨论后的结果，不是我一个人的哦~ 其实我有点担心志向太远大导致开发的成功显得遥遥无期进而影响士气~
2.我们也是这样觉得的~不过我最怕读代码~
3.我们希望核心功能不要依赖和GUI有关的库~然后就可以开发各种各样的frontend了~
4.我们现在缺少懂网络编程的人~谁有兴趣吗？
5.恩~等架构设计出来了就可以分割出具体任务了~

最后谢谢yunfan的关注~

zzh2004linux

我觉得软件应该基于curl函数库开发，它现在都发展到7.X版了，最主要的是它是跨平台的，楼顶的大哥也应该开发可以在WIN下运行的程序。

sjinny

curl是什么……
跨平台还没讨论过，不过目前也许没有这种需求~

zzh2004linux

谁说没有这需求？？？     
curl是一个下载工具去sf.net找就可以了，它有各种语言的接口，很不错的。最主要的是，它可以分块下载，这也是我最关心的。
当然拉，如果能跨平台就可以吸引到更多的程序高手呀，毕竟现在很多人对linux开发模式还持观望态度呀。         

sjinny

强！libcurl似乎很不错啊~~下面是网站上列出的特性：

FEATURES

curl tool
- config file support
- multiple URLs in a single command line
- range "globbing" support: [0-13], {one,two,three}
- multiple file upload on a single command line
- custom maximum transfer rate
- redirectable stderr

libcurl supports
- full URL syntax with no length limit
- custom maximum download time
- custom least download speed acceptable
- custom output result after completion
- guesses protocol from host name unless specified
- uses .netrc
- progress bar/time specs while downloading
- "standard" proxy environment variables support
- compiles on win32 (reported builds on 40+ operating systems)
- selectable network interface for outgoing traffic
- IPv6 support on unix and Windows
- persistant connections
- socks5 support
- supports user name + password in proxy environment variables
- operations through proxy "tunnel" (using CONNECT)
- supports large files (>2GB and >4GB) both upload/download
- replacable memory functions (malloc, free, realloc, etc)
- asynchronous name resolving (*6)

HTTP
- HTTP/1.1 compliant (optionally uses 1.0)
- GET
- PUT
- HEAD
- POST
- multipart formpost (RFC1867-style)
- authentication: Basic, Digest, NTLM(*1), GSS-Negotiate/Negotiate(*3) and
   SPNEGO (*4) to server and proxy
- resume (both GET and PUT)
- follow redirects
- maximum amount of redirects to follow
- custom HTTP request
- cookie get/send fully parsed
- reads/writes the netscape cookie file format
- custom headers (replace/remove internally generated headers)
- custom user-agent string
- custom referer string
- range
- proxy authentication
- time conditions
- via http-proxy
- retrieve file modification date
- Content-Encoding support for deflate and gzip
- "Transfer-Encoding: chunked" support for "uploads"

HTTPS (*1)
- (all the HTTP features)
- using certificates
- verify server certificate
- via http-proxy
- select desired encryption
- force usage of a specific SSL version (SSLv2, SSLv3 or TLSv1)

FTP
- download
- authentication
- kerberos4 (*5)
- active/passive using PORT, EPRT, PASV or EPSV
- single file size information (compare to HTTP HEAD)
- 'type=' URL support
- dir listing
- dir listing names-only
- upload
- upload append
- upload via http-proxy as HTTP PUT
- download resume
- upload resume
- custom ftp commands (before and/or after the transfer)
- simple "range" support
- via http-proxy
- all operations can be tunneled through a http-proxy
- customizable to retrieve file modification date
- third party transfers
- no dir depth limit

FTPS (*1)
- explicit ftps:// support that use SSL on both connections
- implicit "AUTH TSL" and "AUTH SSL" usage to "upgrade" plain ftp://
   connection to use SSL for both or one of the connections

TELNET
- connection negotiation
- custom telnet options
- stdin/stdout I/O

LDAP (*2)
- full LDAP URL support

DICT
- extended DICT URL support

GOPHER
- GET
- via http-proxy

FILE
- URL support
- "uploads"
- resume

FOOTNOTES
=========

  *1 = requires OpenSSL
  *2 = requires OpenLDAP
  *3 = requires a GSSAPI-compliant library, such as Heimdal or similar.
  *4 = requires FBopenssl
  *5 = requires a krb4 library, such as the MIT one or similar.
  *6 = requires c-ares

那么剩下的问题就是……对协议的扩展。因为我们原本希望以后能够通过插件机制来支持更多的协议的，不知道使用libcurl的话能否实现这一特性……

zzh2004linux

加油，加油！        

sagaeon

先顶顶，大家来帮忙啊

sjinny

我想了一点，先拿来讨论：

——————————————————————————————————
插件机制：
一个插件就是一个动态连接库，载入这个连接库后，通过得到的函数可以生成插件对象，通过固有的接口把整个系统的数据枢纽对象的地址传给这个对象，插件对象通过数据枢纽对象可以获得所有它被允许获得的数据，比如任务管理器对象的地址之类的，开发插件时要include数据枢纽对象的头文件。在载入了插件的数据和执行代码后，执行它的初始化函数并借此传入数据枢纽对象的地址，然后剩下的就是两个问题：1.插件如何获得CPU资源来执行它的一些行为；2.插件权限的限制。
对于1，可以分出两种情况，一种是插件对外部事件的被动响应，另一种是插件的主动行为；前者意味着要有事件机制，而且要在插件进行初始化时通过数据枢纽来注册登记自己感兴趣的事件，这样当这些事件发生时就会通知那些对其感兴趣的对象（当然也就包括了插件对象），这个“通知”也就是调用对象的成员函数来传入事件对象，这样插件也就获得了CPU资源来对事件进行分析和响应。对于插件的主动行为，一般来说大多数情况都可以靠被动响应机制来应付（包括那些因时间因素而触发的事件），而目前我还未发现什么情况需要插件能够有主动行为。
对于2，一个插件能够获得任务管理器的地址，但是它可能只被允许调用这个管理器的部分成员函数，这时可以给任务管理器增加一个父类，在这个父类里会有一些虚（virtual）函数，并且它们是纯虚函数，它们就是开放给插件，允许插件调用的成员函数，要开放什么成员函数给插件调用就在这个基类里写成纯虚函数接口就可以了。插件对任务集合进行操作时使用的是以这个类的指针存放的任务管理器对象的地址。


命令机制：
用一个单链表来保存命令对象，按照字符（编码，如ASCII、GB18030等）顺序来排序，如果：
1.如果所有命令都可由不太多的有限个元素组成，如拼音文字（如英文字母和数字等的组合，如所有由ASCII字符表里的字符组成的命令），那么就可以按照字典顺序排列命令对象，在搜索时先搜索第一个组成元素，如第一个字母，如果找不到匹配的命令则可知没有匹配命令，如果找到了那么就从匹配的位置开始向下搜索，每次搜索都比较第一个和第二个组成元素，如果找不到匹配的命令则可知没有匹配命令，如果找到了，就从匹配位置开始向下继续搜索，每次搜索都比较第一个、第二个和第三个组成元素……似乎是个递归？只希望递归次数不要多到栈溢出，因为似乎递归的嵌套层数和命令的长度有关……
可以把一系列的命令写成统一接口的函数的形式，然后都封装入一个动态连接库里，在这个库里还有个事先约定好函数名的函数，在系统载入这个命令集（动态连接库）时，会调用这个函数从而得到两个长度相同的字符串指针数组和数组的长度，这两个数组，一个是保存了所有的命令名，另一个数组里则保存了相对应位置的命令所对应的函数名，根据数组的长度可知将要载入的命令的个数，因此建立一个相应长度的命令对象数组，然后根据返回的数组在动态连接库里查找每一个命令函数并初始化相应的命令对象数组里的数组元素。然后遍历这个命令对象数组，把每一个数组元素都按照字典顺序插入命令链表里，把这个命令对象数组所在的命令集对象加入到命令集对象的链表中。当要删除从某个连接库里读取的所有命令时，可以在命令集对象链表中找到相应的命令集对象，然后遍历其中的命令对象数组，把每个元素都从命令链表里删除（但并不释放其所占用的内存空间），然后释放整个数组（当然是在释放这个命令集对象的过程中执行的）。另外不要忘了及时的、适时的卸载动态连接库。在动态连接库提供的命令之外，系统还有些内建命令，主要内容之一就是对命令集的操作，比如列出所有命令的命令等。
对于一个命令函数，可以使用这样的函数原型：
int cmd(void* data, <数据枢纽>* data_center);
data是命令的参数串，data_center是数据枢纽对象的地址。当然最好能把这两个由传递地址变成传递引用。

sagaeon

好东西啊 :-)

DexterK

小弟用curl开发 bt下载工具是 问题最多了
麻烦阿
所以 我个人对curl不甚好感。

mozilla

我很支持插件机制，像xine一样：UI+引擎＋插件，三部分都是分开的。

不过这个工具跟xine又有一些差别，xine不管播放什么媒体，界面都是一样的，但下载工具不同，比如ftp是基于浏览模式的，而http不是，bt也不是基于浏览模式但跟http又有很大差别，把UI分为主UI＋子窗口（页）插件？如果这样的话就会限定子窗口用的GUI，只能用gtk、qt或其他GUI的其中的一个，混用的话各GUI的事件处理机制不一样更不好弄。如果UI不用插件形式，那对以后扩展又很不利。

sjinny

我现在搞命令解析器……不过因为不会用string类、对STL也不熟所以……

yunfan

你google一下， "c++ string class", 很多介绍

这个里面有类的接口介绍, 和一些例子
http://www.msoe.edu/eecs/ce/courseinfo/stl/string.htm

这个里面有不少例子
http://www.yolinux.com/TUTORIALS/LinuxTutorialC++StringClass.html

我最近也在看string， 看看这些例子就差不多了.