.Share

库的结构得好好设计设计.

就用sqllite吧，感觉这种不大不小的又对查询要求很高的数据结构用这种数据库就很不错；
现在可以统一一下NodeServer了，大站小站都可以用一个版本了；不错

那xml文件还不得越来越大啊.偶试了sqlite,我考!强.写入速度几乎是sql的6倍,读取速度几乎快了一倍.,用它的.net提供程序和sql的.net提供程序.

感觉了一下sqlLite,好像真的可以用嵌入式数据库这种解决方案。。
不错；有待深入研究

@.Share
删除结点,如果不用XmlDocument,就只有使用XmlTextReader + XmlTextWriter了,读一个,写一个,如果是要删除的,就不写.:)

嵌入式数据库有两个:
Berkeley DB
SqlLite

可以试试~

XmlTextWriter是"只进的"-_-b

想删除结点,还是用XmlDocument啊.有其他解决方法吗?

关键是数据库不能安装.如果拿过来就可以用,最好了.

要不用数据库??
有一种嵌入试的数据库来着的,,我不记得名字了,据说性能不错...

对于你说的xml修改的时候必须使用xmldocument这个带缓存的对象；
我觉得可不可以使用xmltextwriter这个轻量级的对象来解决呢？
sdk里的描述:
表示提供快速、非缓存、只进方法的编写器，该方法生成包含 XML 数据（这些数据符合 W3C 可扩展标记语言 (XML) 1.0 和 XML 中命名空间的建议）的流或文件。

你可以先上网搜搜吧~:)

两位能给点相关资料的链接吗？
谢谢

其实做那个CollectionBase的包装主要是想类型明显一些；用arraylist感觉怪怪的；
hBifTs说的确实是很有道理；

还有昨天Nineteen提出，如果去掉ChildNodes集合的话，当删除上级节点的时候，需要查找下级节点并删除，加重运算负担；
我觉得确实存在这个问题，而如果沿用Nineteen的结构的话，当删除上级节点时，调用gc就可以很方便的去掉那些失去引用的无头尸，比较方便；我没有试过，等他弄好了，测试一下便知，如果真的有效的话就很方便了，呵呵

上次看过程序员上的一个文章,说的就是数据库中使用到的BTree.:)

“树”有很多种。据我所知，效率最高的是类似SQLite.org中的核心btree，占用内存不多。

用这个怎样？
class Node
{
string filename; //文件名
Node[] childs; //所有子文件，如果没有则为null
}

这样应该可以节省一点内存
一个数组要保存那些信息？

直接从CollectionBase继承自己的TreeNodeCollection是为了防止对TreeNode对象进行的转换..

就ValueType而言,这样的转换是要进行Box/UnBox操作的.
但是非ValueType好像影响不是很大的啊..应该是一个Cast方法~

如果要使用nineteen的结构，有一个建议：
就是在没有泛型的时期建议将一下字段的类型从ArrayList改为TreeNodeCollection

private System.Collections.ArrayList _ChildNodes = null;
public System.Collections.ArrayList ChildNodes
{
get{return _ChildNodes;}
set{_ChildNodes = value;}
}


TreeNodeCollection 具体实现如下:

public class TreeNodeCollection:System.Collections.CollectionBase
{
public TreeNodeCollection()
{
}

public TreeNode this[ int index ]
{
get
{
return( (TreeNode) List[index] );
}
set
{
List[index] = value;
}
}

public int Add( TreeNode value )
{
return( List.Add( value ) );
}

public int IndexOf( TreeNode value )
{
return( List.IndexOf( value ) );
}

public void Insert( int index, TreeNode value )
{
List.Insert( index, value );
}

public void Remove( TreeNode value )
{
List.Remove( value );
}

public bool Contains( TreeNode value )
{
// If value is not of type TreeNode, this will return false.
return( List.Contains( value ) );
}

protected override void OnInsert( int index, Object value )
{
if ( value.GetType() != Type.GetType("OurnameSpace.TreeNode") )
throw new ArgumentException( "value must be of type TreeNode.", "value" );
}

protected override void OnRemove( int index, Object value )
{
if ( value.GetType() != Type.GetType("OurnameSpace.TreeNode") )
throw new ArgumentException( "value must be of type TreeNode.", "value" );
}

protected override void OnSet( int index, Object oldValue, Object newValue )
{
if ( newValue.GetType() != Type.GetType("OurnameSpace.TreeNode") )
throw new ArgumentException( "newValue must be of type TreeNode.", "newValue" );
}

protected override void OnValidate( Object value )
{
if ( value.GetType() != Type.GetType("OurnameSpace.TreeNode") )
throw new ArgumentException( "value must be of type TreeNode." );
}

}

个人认为如果这个结构仅仅是为了搜索时的节省内存，并且能在搜索到指定目标以后能得到目标的全路径的话，完全可以把一下这个字段去掉：

private System.Collections.ArrayList _ChildNodes = null

public System.Collections.ArrayList ChildNodes
{
get{return _ChildNodes;}
set{_ChildNodes = value;}
}


因为在对目录树进行搜索之后仅从当前节点的ParentNode不断向上递归就可得到当前节点的全路径，每必要保存当前节点的子节点；这样能更有效的减少内存占用

2.在NodeServer初始化的时候,进行扫描,如果管理员们希望它可以像那些ftp服务一样在开机时自动运行,那

么开机时间无疑会大大加长.

如果初始化就加载的话，可以缓慢加载（比如先加载一部分然后暂停然后再加载......如果有搜索请求的时候，就全速加载。这样对启动速度影响不会很大。

4.把缓冲区从ArrayList改成树型的缓冲区.

如果改成树形的话，可以节省大量内存，文件量小的用户直接用内存完全没问题。

6.在文件缓冲区里面,只有files信息,没有directory信息...
文件信息里面只有文件名算了，或者在加一个大小什么的。因为搜索用不到其他信息吧！