专利名称：在服务器和用户之间形成数据流的方法
技术领域：
本发明一般涉及计算机网络，尤其涉及诸如电子邮件应用之类用户和服务器应用之间通信的方法。
背景技术：
电子邮件已经成为通信的重要方法。电子邮件系统一般包括服务器部件(例如，微软的交换服务器(Microsoft Exchange Server))以及用户部件(例如，Microsoft Outlook或Microsoft Outlook Express)。一般把这些部件配置成在计算机设备(例如，服务器、个人计算机(PC)、膝上计算机和个人数字助理(PDA))上执行的软件应用程序。
经常，为了促进通信，诸如电子邮件系统的用户部件和服务器部件之类的用户和服务器同意一种通信协议。协议提出一些规则，这些规则定义通信期间各方的预期性能，例如，请求和响应的预期序列。复杂的协议具有处理未预期性能的规则。
当改进用户和服务器部件时，把改进的版本分发给最终用户。为了利用新部件特征和网络特征，通常的情况是发明新的通信协议。当服务器部件的安装基础有效时，用户部件可以具有通过一组协议用所选择的服务器部件的以前版本协议进行通信的能力。
在有些情况中，在较早协议上编制较晚协议而不是大规模地更换它们。在这种情况中，可以由协议单元来编制较晚协议，可以启动或禁止这些协议单元以便对较早协议进行模拟。同样，当用户部件的安装基础有效时，服务器部件可以具有通过协议用所选择的用户部件的以前版本协议进行通信的能力。
发明概要本发明提供用于改进的用户和服务器通信的一种系统和方法。尤其，本发明针对可以在用户和服务器之间的通信中使用的一种改进的协议。本发明对于电子邮件服务器环境具有特定的关联性，但是可以在其它用户和服务器网络中利用这里描述的特征。
根据本发明的一个方面，电子邮件服务器部件可以提供有差错的数据目标的差错信息来代替由于一个数据目标中存在差错而使整个响应集失效。电子邮件服务器部件可以从电子邮件用户部件接收为多个电子邮件数据目标的一个请求和电子邮件用户部件有能力处理有差错的电子邮件数据目标的一个指示。响应于请求和指示，电子邮件服务器部件可以检索多个电子邮件数据目标，对于每个电子邮件数据目标，如果在打开电子邮件数据目标中没有差错发生，则把电子邮件数据目标发送给电子邮件用户部件。然而，如果在打开电子邮件数据目标中发生差错，则电子邮件服务器部件把差错消息发送给电子邮件用户部件。
根据本发明的另一个方面，电子邮件服务器部件可以把进展数据(progress data)提供给电子邮件用户部件，以致电子邮件用户部件可以跟踪来自电子邮件服务器部件的下载的进展。电子邮件用户部件发送为多个电子邮件数据目标的一个请求和电子邮件用户部件有能力处理进展模式数据的一个指示。响应于请求和指示，电子邮件服务器部件检索多个电子邮件数据目标，并把进展模式数据与多个数据目标一起提供给电子邮件用户部件。进展模式数据可以包括多个电子邮件数据目标的大小、每个目标的大小、目标的数目、目标是否为与信息、附加信息或这些项目的任何组合相关联的文件夹。
根据本发明的又一个方面，电子邮件用户部件发送的请求可以表示对于请求的响应没有大小的限制，如果需要的话，允许电子邮件服务器部件填充一个缓冲器。电子邮件用户部件发送一个请求中的多个子请求，每个子请求请求电子邮件服务器部件处的一个操作以及包括大小信息。响应于每个子请求，如果大小信息包括电子邮件服务器部件预期范围内的大小极限，则电子邮件服务器部件把响应限制到大小极限。如果大小信息包括电子邮件服务器部件预期范围外的大小极限，则电子邮件服务器部件寻找大小信息中的新的大小极限。新的大小极限可以是任意的，诸如“填充可用的缓冲器”。
附图简述
图1是通过网络连接的计算机的示意图。
图2是示意图，示出可用于实施本发明的一个实施例的示例计算机系统。
图3是示意图，描绘具有电子邮件用户部件和电子邮件服务器部件的多种版本的一种环境。
图4是协议图，示出电子邮件用户部件和电子邮件服务器部件之间的协议协商过程的一个例子。
图5是示意图，示出电子邮件网络的一个例子，其中电子邮件用户部件和电子邮件服务器部件具有固定大小通信缓冲器。
图6A是协议图，示出需要两个请求—响应周期来完成一个快速传送操作的一个示例协议。
图6B是协议图，示出需要单个请求—响应周期来完成一个快速传送操作的一个示例协议。
图7A是流程图，描绘用于把电子邮件消息主体发送到电子邮件用户部件的一个示例过程。
图7B是根据本发明一个方面的流程图，描绘用于把电子邮件消息主体发送到电子邮件用户部件的一个过程。
图8A是程序图，示出全项目传送模式。
图8B是程序图，示出先传送标头模式。
图8C是程序图，示出只传送标头模式。
图8D是程序图，示出先传送标头模式或只传送标头模式的例外情况。
图9是示意图，示出随时间变化的电子邮件用户部件的原籍电子邮件服务器部件。
图10是协议图，示出用于同步电子邮件用户部件和电子邮件服务器部件之间的电子邮件文件夹的一个示例协议。
图11A是流程图，描绘使部分状态区最优化的示例过程。
图11B是根据本发明的流程图，描绘使部分状态区最优化的一个过程。
图12是示意图，示出电子邮件文件夹层次。
图13是根据本发明的一个方面，示出用于同步和保持电子邮件消息存储器的同步的一个示例协议的协议图。
图14A是协议图，示出在ROP级处传送差错信息的一个示例协议。
图14B是根据本发明的一个方面的协议图，示出用于在每消息基础上传送差错信息的一个示例协议。
图15A是流程图，描绘用于在ROP电平上生成差错信息的一个过程。
图15B是根据本发明的流程图，描绘用于在每消息基础上生成差错信息的一个过程。
图16A是协议图，示出用于执行快速传送操作的一个示例协议。
图16B是根据本发明的一个方面，示出用于提供在执行快速传送操作的同时提供进展信息的一个示例协议的协议图。
图17A是流程图，描绘用于流式输出一组消息的一个过程。
图17B是根据本发明的一个方面，示出用于流式输出一组消息与进展信息的一个过程的流程图。
图18是示意图，其中把在电子邮件服务器部件处的相同数据目标的改变作为结果通知多个电子邮件用户部件。
图19A是流程图，描绘通知多个签约用户的一个过程。
图19B是根据本发明的一个方面，描绘用于通知多个签约用户的一个过程的流程图。
图20是根据本发明的一个方面，描绘用于提供使用所要求代码页的电子邮件消息的一个过程的流程图。
本发明的详细说明在进行本发明的各个实施例的描述之前，现在将先提供可以实现本发明的各个实施例的计算机和网络环境的说明。虽然并非要求，但是可以通过计算机执行的程序来实施本发明。一般，程序包括执行特定任务或实施特定抽象数据类型的例行程序、目标、部件、数据结构等。这里所使用的术语“程序”的内涵可以是一致动作的单个程序模块或多个程序模块。这里所使用的术语“计算机”包括在电气上执行一个或多个程序的任何设备，诸如个人计算机(PC)、手持设备、多处理器系统、基于微处理器的可编程消费电子产品、网络PC、小型计算机、图形板PC、主计算机、具有微处理器、或微控制器、路由器、网关、集线器等的消费电器。可以在分布式计算环境中使用本发明，在该环境中通过通信网络链接的远程处理设备来执行任务。在分布式计算环境中，可以使程序存储于本地或远程存储器存储装置中。
现在将参考图1描述可以使用本发明的网络化环境的一个例子。示例网络包括在通过云表示的网络11上相互通信的数台计算机10。网络11可以包括任何已知部件，诸如路由器、网关、集线器等，并允许计算机10通过有线和/或无线媒体进行通信。当通过网络11相互交互作用时，一台或多台计算机的作用如同用户、服务器或相对于其它计算机的同位体。因此，可以在用户、服务器、同位体或它们的组合上实施本发明的各个实施例，虽然这里包含的特定实施例并不涉及所有这些类型的计算机。
参考图2，在图中示出计算机基本配置的一个例子，可以实施这里描述的本发明的全部或一部分。在它的最基本配置中，计算机10一般包括至少一个处理单元14和存储器16。处理单元14执行指令以进行根据本发明的各个实施例的任务。在进行这种任务时，处理单元14可以把电子信号发送到计算机10的其它部分和发送到计算机10外部的设备以导致相同的结果。根据计算机10的确切配置和类型，存储器16可以是易失性的(诸如RAM)，非易失性的(诸如ROM或快闪存储器)或两者的某种组合。在图2中通过虚线18示出这种最基本的配置。此外，计算机还可以具有附加的特征/功能性。例如，计算机10还可以包括附加的存储单元(可拆卸的201和/或不可拆卸的202)包括，但是不限于，磁盘或光盘或磁带。计算机存储媒体包括为了存储信息，以任何方法或技术实施的易失性和非易失性、可拆卸和不可拆卸媒体包括计算机可执行指令、数据结构、程序模块或其它数据。计算机存储媒体包括，但是不限于，RAM、ROM、EEPROM、快闪存储器、CD-ROM、数字通用盘(DVD)或其它光学存储器、盒式磁带、磁带、磁盘存储器或其它磁性存储器件、或可以用来存储所需要信息和计算机10可以访问的任何其它媒体。任何如此的计算机存储媒体可以是计算机10的一部分。
计算机10最好还包括允许设备与其它设备进行通信的通信连接205。通信连接是通信媒体的一个例子。通信媒体一般在诸如载波或其它传送机构之类的调制数据信号中实施计算机可读出指令、数据指令、程序模块或其它数据，以及包括任何信息传送媒体。作为例子，但是不作为限制，术语“通信媒体”包括诸如有线网络或直接—有线连接之类的有线媒体以及诸如声音、RF(射频)、红外线之类的无线媒体和其它无线媒体。这里所使用的术语“计算机可读出媒体”包括计算机存储媒体和通信媒体两者。
计算机10还可以具有诸如键盘、鼠标、笔、话音设备、触摸输入设备等的输入设备204。还可以包括诸如显示器20、扬声器、打印机等输出设备203。所有这些设备本技术领域中是众知的，这里不需要多述。
本发明针对用于改进的用户和服务器通信的一种系统和方法，尤其，针对一种改进的协议，这种协议可以用于用户和服务器之间的通信。本发明特别与电子邮件服务器环境相关，但是可以把这里描述的特征利用于其它用户和服务器网络。然而，为了便于说明，参考用户/服务器电子邮件环境来描述本发明。
可以在具有两种或多种版本的用户应用程序或部件和/或两种或多种版本的服务器应用程序或部件的用户/服务器环境中实施本发明。为此，图3示出方框图，图中示出网络电子邮件环境中用户和服务器部件两者的多种版本。一般，配置用户和服务器部件，以致它们是可反向地兼容的。即，用户部件能够与服务器部件的最新的和传统的(legacy)版本进行通信，反之亦然。建立一组协议以在多种版本之间进行通信。协议组可以构成数个不同的协议，每个协议是自含的。另一种方法是，一组协议部件可以是可得到的，并使用特定部件来配置协议组中的特定协议。
在任何情况中，在图3示出的网络电子邮件环境中，最新版本电子邮件用户部件303使用协议307与最新版本电子邮件服务器部件306进行通信为最佳。然而，使用协议组中的其它协议(例如，图3中的协议308和309)，最新电子邮件服务器部件306也能够与所选择的以前版本电子邮件用户部件，例如电子邮件用户部件302和电子邮件用户部件301进行通信。使用诸如协议310和311之类的协议，电子邮件用户部件303也能够与所选择的以前版本电子邮件服务器部件，例如电子邮件服务器部件305和电子邮件服务器部件304进行通信。
一般，如这里所使用，为了描述本发明的协议的目的，“最新”电子邮件(服务器或用户)部件或最新版本电子邮件(服务器或用户)部件是已经知道其新特征或正在描述的特征的一种服务器或用户部件，并且可以根据这些特征进行利用、实施和/或动作。虽然在整个本文件中使用术语来描述已经知道本发明的协议的各个方面的用户和服务器部件，但是该术语还包括只知道正在描述的特定方面，或正在描述的一个以上的方面的一些部件。同样“以前的”电子邮件部件或以前版本的电子邮件部件是不知道本发明的协议的各个方面和不能根据本发明的协议的各个方面动作的一种部件。
经常使用协议协商过程来建立用户和服务器(例如，最新版本电子邮件服务器部件306和最新版本电子邮件用户部件303)之间的协议。虽然这种协议协商是已知的，但是为了读者的利益，提供电子邮件用户部件401(图4)和电子邮件服务器部件402(也是图4)之间的协议协商过程的简单说明。在电子邮件用户部件401和电子邮件服务器部件402通信会话的早期，电子邮件用户部件401把消息403发送到电子邮件服务器部件402，例如，该消息包括按用户部件版本商标的形式的用户版本信息。电子邮件服务器部件402用消息404来响应消息403，例如，所述消息404包括按服务器部件版本商标形式的服务器版本信息。
可以在多种方式中使用用户和服务器版本信息，试图建立电子邮件用户部件401和电子邮件服务器部件402之间的通信。例如，可以使用版本信息来选择继续进行通信的合适的协议，或决定是否还有可能进一步通信。例如，在建立协议时，可以使用版本信息来启动和/或禁止可得到的特定协议方面或部件。
电子邮件服务器部件可以并行接收和处理来自多个电子邮件用户部件的请求。除非另行明确地指出，所示出的单个用户只是为了简化附图和所伴随的说明。
本发明的电子邮件网络利用请求和响应交换而在网络中的用户和服务器部件之间传递询问和数据，实际上，在电子邮件网络中用于实施用户和服务器之间通信的基础通信网络传送机构会影响协议的性能。例如，在使用远程过程调用(RPC)作为基础通信网络传送机构的电子邮件网络中，使单个远程过程调用具有较大容量(例如，32KB)要比使数个远程过程调用具有较小容量(例如，2KB)更有效。改进这种电子邮件网络的性能的一种已知方法是对多个请求和/或响应进行缓冲，以便在单个远程过程调用中发送。
作为一个例子，图5示出电子邮件用户部件501和电子邮件服务器部件502之间的请求和响应交换。电子邮件用户部件501和电子邮件服务器部件502的每一个具有固定大小的通信缓冲器503、504、505和506。缓冲器503、504、505和506是暂时保存数据的存储器的保留区域。在把缓冲器503的内容发送到缓冲器504之前，电子邮件用户部件501通过用一个或多个子请求或远程操作(ROP)填充缓冲器503而开始请求—响应周期。
在缓冲器504中接收之后，电子邮件服务器部件502按次序处理每个ROP，并把对应的结果写入缓冲器505。每个ROP确实都产生某些结果。结果可以包括电子邮件用户部件501请求的数据，例如，一组特定的电子邮件消息。电子邮件服务器部件502监测缓冲器505，当它接近充满时(例如，所剩余的小于8KB)，电子邮件服务器部件502把任何未处理的ROP写入缓冲器505的末端，并把缓冲器505发送到缓冲器506。然后当缓冲器503变成再次充满时电子邮件用户部件501通过把未处理的ROP写入缓冲器503以便再提交给电子邮件服务器部件502而开始新的请求—响应周期。
响应的大小一般平均大于请求的大小。为了这个原因，一般配置响应缓冲器505和506的大小使之大于请求缓冲器503和504的大小。在本发明的一个实施例中，对于32KB大小的请求缓冲器503和504，确定响应缓冲器505和506的最优化大小为96KB，为3比1的比值。在一个实施例中，电子邮件用户部件能够配置任何缓冲器503、504、505和506的大小。
使用缓冲器的某些电子邮件网络(例如在图5中示出的电子邮件网络)可以使用电子邮件用户部件和电子邮件服务器部件之间的快速传送模式。快速传送模式包括诸如ROP之类的至少分成两类的用户请求导致服务器处的快速传送数据源初始化的一些请求，以及导致从快速传送数据源到用户的有效数据传送的一些请求。例如，快速传送数据源可以是数据库表格。快速传送数据源的作用为数据准备暂时存储，这些数据启动以后的请求，使所服务的数据比春他可能情况具有较小的延迟。有时第二类快速传送模式请求通过明确地指定响应的大小而寻找得到有效的数据传送，例如，可以把响应的大小设置成较少响应额外开销的整个用户接收缓冲器的大小。
图6A示出具有至少两个请求—响应周期的快速传送操作。在第一请求601中，ROP(例如，FXPrepare)对服务器502上的快速传送数据源进行初始化。在服务器处，只处理FXPrepare(即，使快速传送数据源初始化)，并在第一响应602中返回它的结果。在第二请求603中，ROP(例如，FXGetBuffer)请求服务器从快速传送数据源填充缓冲器505。服务器使快速传送数据源出空到缓冲器，并在第二响应604中返回结果。如果电子邮件服务器部件的输出缓冲器505在快速传送数据源出空之前已经充满，则可以要求另外的FXGetBuffer。
图6B示出只具有单个请求—响应周期的快速传送操作。在第一请求605中，通过电子邮件服务器部件502处理FXPrepare和FXGetBuffer两者，并在第一响应606中返回两种操作的结果。在电子邮件服务器部件502处FXGetBuffer可以采用FXPrepare的结果，因为明确地定义每个缓冲器503、504、505和506的一部分为共享数据表格。希望减少请求—响应周期数，因为这样导致更有效地传送数据。当缓冲器505太满以致不能保存FXGetBuffer ROP的结果时，可能发生比只具有单个请求—响应周期具有更多的周期的快速传送操作。
可以理解，除非另行特别指定，在整个本申请中的图6A和6B以及相似附图中的ROP是示意性的，实际上可以通过一系列ROP来实施它们。
一般，ROP结果的大小与ROP请求的大小不同。预测ROP结果的大小经常是不可能的。当使用数据压缩技术来减小ROP结果的大小时，预测ROP结果的大小甚至更困难。不能够预测ROP结果的大小可以防止协议的人工调谐，以减小完成特定用户操作所需要的请求—响应周期数目，例如，保证在单个请求—响应周期中把所有新消息下载到用户。协议的人工协调包括人工配置协议请求、响应和/或ROP的序列和/或大小。
根据本发明的一个方面，通过规定关键ROP(例如，FXGetBuffer)不受预测它们的结果大小的要求的约束而自动地使请求—响应周期的数目减至最少。作为替代，通过电子邮件服务器部件502处理这种ROP直到达到缓冲器505(它和缓冲器506是相同的)的极限。
作为一个例子，在包括多个版本的电子邮件服务器部件的一个环境中，可以对于以前版本服务器部件和最新版本服务器部件定义单独的ROP。最新版本不受预测它们的结果大小的要求的约束。在下列表格中表示这些ROP的特征
以前版本服务器部件的ROP在结构上与存在的现有技术ROP相似。即，ROP预测和确定必须为了保存响应而保留的输出缓冲器(例如，发送缓冲器505)的大小。相反，最新版本服务器部件的输出缓冲器的确定大小是不预测的，而是设置一个值超过以前版本服务器部件预期最大值，例如，设置到大于32KB的一个值。定义输出缓冲器的大小超过服务器部件预期的一个值的事实发信号给服务器部件使之寻找新的大小极限参数，例如，它可以是为服务器部件填充输出缓冲器。这些特征自动地使请求—响应周期数减至最少，而处理ROP的电子邮件服务器部件的复杂度只增加了一点点。
注意，例如，在上述表格中和整个本申请的相似表格中所示出的参数的排序不必定与通过电子邮件用户部件或电子邮件服务器部件在网络上发送的参数或存储在存储器中的参数的排序相关，除非同时发生对于相反情况的明确的陈述。此外，为了清楚起见，可以忽略未改变的参数。
在电子邮件网络中，协议的一般任务中之一是得到电子邮件用户部件和电子邮件服务器部件之间的数据目标(例如，电子邮件消息)的传送。这种数据目标的进一步例子包括可以包括含有电子邮件消息和其它数据目标的电子邮件文件夹，以及文件夹相关联信息(FAI)数据目标，例如，它可以包括处理电子邮件消息的规则，或定义如何显示文件夹所包含的数据目标。数据目标对于电子邮件用户部件可以是含糊的，即，电子邮件用户部件可能无法解译数据目标的内容。另一方法是，可以由定名称的特性来构成数据目标，例如电子邮件消息可以包括一些特性，这些特性的名称为“到”、“从”、“主题”、“重要”、“主体1”、“主体2”、“主体3”、“附件1”、“附件2”，依次类推。
由于只传送一部分数据目标的协议能力，在数据目标是含糊的电子邮件网络上，由定名称的特性构成数据目标的电子邮件网络的一个优点是改进协议性能的潜力。具有定名称的特性允许发送数据目标的特定特性而无需发送整个数据目标。
例如，可以由一组标头特性和一组主体特性来构成电子邮件消息。电子邮件用户部件的需要是如此的，协议先传送标头特性，较晚时间再传送或并不传送主体特性。这个特征允许用户在下载所有消息的整体之前先观看数个消息的标头信息。使用这个特征，通过必定可以影响协议性能的用户部件可以达到带宽利用方面取得更精密的控制。此外，用户部件可以使用这个特征而导致带宽利用的减少(例如，可以只对所选择的标头下载主体)，这在低带宽环境中是特别需要的。
如果配置服务器部件使之在两个独立的请求—响应周期(即，标头和主体各一个请求—响应周期)中发送主体和标头特性，则不需提高协议的性能。例如，如果电子邮件用户部件的需要是如此的，致使它同时需要标头和主体特性两者，则与单个请求—响应周期可以检索标头和主体两者的情况比较，会降低协议的性能。因此，启动由定名称特性构成的数据目标的简单动作的本身不足以自动地产生提高的协议性能。提高的协议性能的获得要取决于对构成数据目标的特性的选择以及协议如何使用它们。可以根据许多因素来进行选择，这些因素包括最新和以前版本电子邮件用户部件的需要以及最新和以前版本电子邮件服务器部件的需要。电子邮件用户部件的需要的例子包括满足显示不同信息的不同紧迫程度以及符合电子邮件用户部件所设置的优选。电子邮件服务器部件需要的例子包括有效地存储和检索数据以及有效地处理协议请求。
传统的现有技术电子邮件环境利用可以通过定名称特性构成的数据目标，例如，可以包括定名称特性的标头组和主体组的电子邮件消息，以致可以分开请求两个组和/或分开处理。另一个现有技术例子是一种电子邮件消息，其中定名称特性的主体组包括多个版本的电子邮件消息主体，例如，按诸如明文、超文本标签语言(HTML)、普适文本格式(RFT格式)等等多个电子邮件消息格式。在这种情况中，现有技术电子邮件服务器部件可以按许多方式响应电子邮件消息的主体的协议请求。复杂度最小的响应可以是发送所有版本的电子邮件消息主体，但是这个响应会导致带宽利用的增加。
图7A描绘以前(现有技术)版本电子邮件服务器部件用来响应这种情况的部分过程。在步骤701中，电子邮件服务器部件检查每个电子邮件消息主体的格式。如果格式中之一是预定的标准格式(例如，RFT)，则过程转移到步骤703，并把标准格式电子邮件消息主体发送到请求电子邮件用户部件。如果没有一个格式是预定标准格式，则步骤701转移到步骤702，把电子邮件消息主体版本中之一转换成标准格式。当只有单个电子邮件消息主体的版本但此电子邮件消息主体不是协议所要求的标准格式时，还可以使用图7A描绘的子过程。
图7B描绘根据本发明的最新版本电子邮件服务器部件使用的部分过程。在步骤704中，为BEST_BODY(最佳主体)标志检查导致电子邮件服务器部件使用本子过程的协议请求。对于是最新版本并且希望执行与标志相关联的功能的电子邮件用户部件，使用本例子中的标志和这里使用的其它标志。可以使用其它表示。例如，如果检测到最新电子邮件用户部件，则可以通过缺省值来执行功能。
在任何情况中，如果没有找到BEST_BODY标志，则步骤704转移到步骤701，并且如参考图7A描述的那样继续进行。
如果找到标志，则过程转移到步骤705，在该步骤中选择用于发送到请求电子邮件用户部件的最佳电子邮件消息主体。如果只有单个电子邮件消息主体与所请求的电子邮件消息相关联，则这是最佳的。如果可得到数个电子邮件消息主体，例如，具有不同的格式，则电子邮件服务器部件根据，例如，电子邮件消息主体格式(例如，RFT、HTML、明文)的预定等级从它们中间选择最佳的。然后过程进行到步骤703，在该步骤中，把所选择的电子邮件消息主体发送到电子邮件用户部件。在本实施例中，电子邮件用户部件可能能够显示多种电子邮件消息主体格式，因此使电子邮件服务器部件不需要把电子邮件消息主体转换成标准格式。此外，如果需要的话，电子邮件用户部件可以把最佳电子邮件消息主体转换成标准格式。
因为减轻了电子邮件服务器部件转换电子邮件消息主体的任务，所以本发明提供了改进的性能。此外，最新版本电子邮件服务器部件可以响应来自以前版本电子邮件用户部件的协议请求，而只适度地增加了复杂度。
可以使用ROP来复制电子邮件服务器部件和电子邮件用户部件之间的电子邮件文件夹。例如，可以通过Synchfolder ROP进行同步文件夹的请求。在电子邮件用户部件能够显示非标准电子邮件消息主体格式时，它可以在Synchfolder ROP中设置BEST_BODY标志来表示电子邮件服务器部件可以从可得到电子邮件消息主体中选择最佳格式，而不是要求服务器返回标准格式的电子邮件消息主体。电子邮件服务器部件可以恰当地处理具有或不具有BEST_BODY标志的ROP，而只适度地增加了复杂度。例如，用于与以前版本和最新版本服务器通信的ROP可以包括下面表格中设置的特征
图8A-8C示出在电子邮件服务器部件和电子邮件用户部件之间传送电子邮件消息组的几种不同的现有模式。对于每种模式，每个电子邮件消息具有包括标头组和主体组的定名称的特性，并且在文件夹中包括数个电子邮件消息。图8A示出全项目传送模式。示意图示出传送第一电子邮件消息标头801，然后在第二电子邮件消息标头803之前传送第一电子邮件消息主体802，然后第二电子邮件消息主体804，依次类推，直到已经传送了电子邮件消息组。图8B示出先传送标头模式。在这个模式中，传送第一电子邮件消息标头805，然后第二电子邮件消息标头806，依次类推，直到已经传送了所有电子邮件消息标头，只有此时才传送第一电子邮件消息主体807，然后第二电子邮件消息主体808，依次类推，直到已经传送了电子邮件消息组。图8C示出只传送标头模式。如该名称所暗示，根据传送电子邮件消息组的请求只传送电子邮件消息标头809。只有根据另外的明确请求才传送电子邮件消息主体810。例如，在这些模式的任何一种中，对于特定的电子邮件消息主体，更高优先级电子邮件用户部件请求可以暂时中断传送序列。
电子邮件文件夹是请求传送一组电子邮件消息的目标的一个例子。然而，电子邮件文件夹可以包括不同于电子邮件消息的数据目标。如上所述，经常参考电子邮件消息标头和电子邮件消息主体来定义传送模式，诸如先传送标头模式和只传送标头模式。在这些传送模式中，试图传送没有很好地定义的定名称特性的标头组和/或定名称特性的主体组的数据目标可能会导致协议失效。本发明的一个方面通过对于没有很好地定义的定名称特性的标头组和/或定名称特性的主体组的数据目标始终全部传送而不是只传送一部分而避免了这种情况。通过图8D的例子示出这个实施例。在这个例子中，电子邮件服务器部件和电子邮件用户部件之间的传送可以发生在只传送标头模式中。因此，首先传送第一电子邮件消息标头811，然后数据目标812变成下一个传送候选者。对于数据目标812，诸如FAI，没有很好地定义定名称特性的标头组，所以传送整个数据目标。传送的下一个候选者具有很好定义的定名称特性(即，候选数据目标拥有所有的定名称特性，这些定名称特性是电子邮件用户部件明确地定义的、作为属于定名称特性的标头组的)的标头组，所以只传送电子邮件消息标头813。
实施本发明的这个方面的一种方法的例子是使用可以包括在同步ROP(诸如上述Synchfolder ROP)中的、诸如IGNORE_MODE_ON_FAI之类的标志。电子邮件服务器部件可以恰当地处理具有或不具有IGNORE-MODE_ON_FAI标志的ROP，而只适度地增加了复杂度。ROP可以包括下表中设置的特征，以复制电子邮件服务器部件和电子邮件用户部件之间电子邮件文件夹
一般使电子邮件消息寻址到一个或多个电子邮件网络用户。如果电子邮件服务器部件接收电子邮件消息而存储，则认为传递了该电子邮件消息。电子邮件网络可以有数个电子邮件服务器部件。一般，电子邮件网络协议具有某些策略，这些策略对电子邮件网络用户为了新消息而必须检查的电子邮件服务器部件的数量进行限制。普通的例子是原籍服务器策略，它提供只由一个特定电子邮件服务器部件(称之为用户的原籍服务器)接收寻址到特定电子邮件网络用户的电子邮件消息。在这种情况中，例如，当周期性地检查新电子邮件消息或登记新电子邮件消息的通知时，电子邮件用户部件只考虑配置原籍服务器。
图9示出即使一种简单的原籍服务器策略例子也可能具有复杂性。在图9示出的例子中，首先指定特定电子邮件服务器部件901作为特定电子邮件网络用户的原籍服务器。随时间的变化，一般为了管理的目的，把为用户指定的原籍服务器改变成不同的电子邮件服务器部件903和905。例如，电子邮件服务器部件901、903和905可以是物理上不同的，或逻辑上不同的，或是不同版本的。从时间T0到T1，电子邮件用户部件902可以只与电子邮件服务器部件901进行通信，然后电子邮件用户部件904可以只与电子邮件服务器部件903进行通信直到T2，然后电子邮件用户部件906可以只与电子邮件服务器部件905进行通信。电子邮件用户部件902、904和906可以是相同的或不同的。在时间T2之后，电子邮件服务器部件901和903可以存在或不存在。这些复杂性特别与接着讨论的电子邮件消息存储器复制相关。
电子邮件服务器部件可以把电子邮件消息存储器在明确的电子邮件消息存储器中，例如，可以使用众知的数据库技术来实施这种电子邮件消息存储器。电子邮件服务器部件可以具有一个或多个如此的消息存储器。电子邮件网络用户可以具有原籍消息存储器。改变原籍消息存储器可以具有如改变原籍服务器所述的同样的作用。
某些电子邮件网络协议包括把部分电子邮件消息存储器复制到电子邮件用户部件的本地存储器设备中的能力。把部分远程电子邮件消息存储器复制到本地电子邮件存储设备可以改进协议性能和/或感觉的协议性能，例如，通过在明确的电子邮件网络用户请求观看所有新的电子邮件消息之前把它们复制到本地电子邮件存储设备中。这种复制还可以提供附加的电子邮件用户部件功能，例如，使电子邮件网络用户在网络连接中断期间观看电子邮件消息。
在电子邮件网络环境中，简单的复制可能较快就变成无效。例如，如果电子邮件服务器部件具有与特定电子邮件网络用户相关联的一个电子邮件消息，并且该消息在用户部件处已经为网络用户复制过，以及为该电子邮件网络用户的新的电子邮件消息到达，则根据简单的复制请求仍要求必须发送两个电子邮件消息。如果在复制两个电子邮件消息之后，另一个新电子邮件消息到达，则根据简单的复制请求仍要求现在必须发送三个电子邮件消息，依次类推。某些电子邮件网络协议配备有电子邮件消息存储器的递增复制，以减轻这个问题。在递增复制中，只在根据复制请求必须发送以前的成功递增复制之后才出现对于电子邮件消息存储器的改变，例如，在由于最后成功的递增复制的仅有改变是新电子邮件消息的到达时，那么根据递增复制请求只需要发送新电子邮件消息。
图10示出配备递增复制的协议的更详细的例子。可以把电子邮件消息存储器细分成电子邮件文件夹。每个电子邮件文件夹可以独立于其它文件夹而复制，在复制过程上提供更精细的控制。在这个例子中，把递增复制称为同步，因为它包括从电子邮件用户部件501到电子邮件服务器部件502以及从电子邮件服务器部件502到电子邮件用户部件501来传播改变。在同步请求1001之后，电子邮件服务器部件502处理Synchfolder ROP。ROP包括folderID(文件夹识别符)参数(未示出)以及stateblob0(状态区)参数。folderID参数识别作为同步请求1001的目标的电子邮件文件夹。stateblob0参数包括信息，这种信息允许电子邮件服务器部件502确定自从最后同步以来电子邮件文件夹已经发生了什么改变，如果有改变的话。如果请求1001表示电子邮件用户部件501对于目标文件夹的始终第一的同步请求，则电子邮件服务器部件502比较空文件夹而确定在电子邮件消息存储器中的目标电子邮件文件夹是否改变。作为对于请求1001的响应1002，电子邮件服务器部件502把任何改变发送到电子邮件用户部件501，包括任何电子邮件消息和/或已经添加到目标文件夹中的其它数据目标以及任何电子邮件消息和/或已经从目标文件夹删除的其它数据目标的列表。电子邮件服务器部件502还创建表示目标文件夹的状态的新的stateblob1，它将紧接在同步之后存在于电子邮件用户部件501上，并且还在响应1002中发送该stateblob1。当电子邮件用户部件501发送对于请求1001中相同文件夹的下一个同步请求1003时，则请求1003将包括用响应1002返回的相同的stateblob1作为参数。如前所述，电子邮件服务器部件502将使用包括在stateblob1中的信息来确定在目标文件夹中已经发生什么改变，如果有改变的话。并且在响应1004中把这些改变与新创建的stateblob2一起返回给电子邮件用户部件501。
如果stateblob数据目标的大小较大，它可能对于协议性能有负面影响，因为它是与每个电子邮件文件夹同步请求一起发送到电子邮件服务器部件的，并且它也来自电子邮件服务器部件。在配备电子邮件文件夹同步的某些电子邮件网络协议中，一组消息changeID数据目标可以构成大部分stateblob，所述消息changeID(改变识别符)数据目标可识别电子邮件用户部件已经看到的电子邮件消息的改变。当把已改变的电子邮件消息传送到电子邮件用户和/或服务器部件时，可以说电子邮件消息改变已经被该部件看到。
消息changeID数据目标一个目的是唯一地可以识别在整个电子邮件网络的情况中的电子邮件消息的改变。在使用原籍服务器策略的电子邮件网络中，用户的原籍服务器可以负责使消息changeID数据目标与以前未看到的电子邮件消息改变相关联。例如，原籍服务器可以使用包括serverID(服务器识别符)数据目标和串号的消息changeID数据目标。serverID数据目标可以使用诸如全球化唯一识别符之类的众知技术来唯一地识别在整个电子邮件网络的情况中电子邮件服务器部件。当这种识别符本身的大小很大时，可以把serverID数据目标替代由电子邮件服务器部件所保持的识别符查找表中的索引。例如，宽度为6字节的、电子邮件服务器部件的本地的计数器可以提供串号，每当电子邮件服务器部件接收用于存储的、以前未看到的电子邮件消息时，就递增所述串号。
为了讨论的目的，例如，可以通过“S11”表示消息changeID数据目标，其中‘S1’表示第一电子邮件服务器部件的serverID数据目标，而‘1’表示串号。例如，可以通过“S11，S12，S13”来表示一组消息changeID数据目标，其中“S11”、“S12”、“S13”是具有serverID S1的电子邮件服务器部件所使用的连续的消息changeID数据目标。
在由表示电子邮件用户部件所看到的电子邮件消息改变的一组消息changeID数据目标(“看到的消息改变”组，a“Message Changes Seen”set)构成大部分状态区时，已经开发某些技术来对组进行编码以便减少它的大小，例如，可以把组“S11，S12，S13，S14”编码成“S11-4”。此外，电子邮件服务器部件可以保证它使用的串号总是增加的。在该情况中，可以把非邻近的“看到的消息改变”组，例如，“S11，S13，S15，S17”，编码成“S11-7”，即，当范围包括最小和最大串号时，不会丢失功能。
在图9描绘的一种情况中，“看到的消息改变”组可以包括由不同于当前原籍服务器(例如，S3)的电子邮件服务器部件(例如，S1，S2)创建的消息changeID数据目标。可以把当前原籍服务器创建的消息changeID数据目标称为本土消息changeID，可以把其它电子邮件服务器部件创建的消息changeID数据目标称为外来消息changeID。用于与以前版本电子邮件服务器部件通信的电子邮件网络协议未曾配备在每电子邮件服务器部件基础上作为包括最小和最大串号范围的非邻近外来消息changeID序列的最优化。下列表格示出本发明的实施例中包括这种最优化的利益。
本发明的一个实施例使用包括下面表格中设置的特征的ROP，以得到电子邮件服务器部件和电子邮件用户部件之间的电子邮件文件夹的同步。电子邮件服务器部件可以执行改进的状态区编码技术，而只适度地增加了复杂度。
图11A和11B描绘可以分别由以前版本服务器和最新版本服务器所使用的以响应Synchfolder ROP的子过程之间的差异。图11A示出步骤1101、1102和1103。在步骤1101处，构建初始“看到的消息改变”组。在步骤1102处，使“看到的消息改变”组(是本土消息changeID数据目标)的成员最优化。在步骤1103处，把经最优化的“看到的消息改变”组添加到可以与响应一起发送到请求同步的电子邮件用户部件的状态区数据目标中。图11B包括附加步骤1104，该步骤示出“看到的消息改变”组成员是在“看到的消息改变”组之前，用改进的最优化而加以最优化的外来的消息changeID数据目标，在步骤1103处加至状态区数据目标中。
在把电子邮件消息存储器细分为电子邮件文件夹，可在同步过程上提供更精细的控制时，它不会自动地提供协议性能的改进，而可能导致协议性能的降级。例如，某些协议要求每个消息存储文件夹独立地同步。一般，每个同步操作都具有一些额外开销，而该额外开销可能是较大的。利用状态区数据目标的同步操作是可能具有较大额外开销的操作的一个例子。在同步整个消息存储的情况中，与要求较少同步操作的协议比较，要求每个消息存储文件夹独立地同步的协议可能处于不利地位。
对于电子邮件用户部件，同步整个消息存储和保持同步是一个要求的目标。传统的现有技术电子邮件用户部件已经探索来达到这个目标，甚至当它对协议性能造成较大的负面影响时。本发明的一个方面是能够通过利用深层次表格而使负面协议影响最小，同时达到这个目标。传统的现有技术电子邮件服务器部件不能提供深层次表格。
在把电子邮件消息存储器细分成电子邮件文件夹时，可以把这些电子邮件文件夹组成层次。图12示出电子邮件文件夹层次的一个例子。在图12中，文件夹1204是文件夹1203的子文件夹。文件夹1203依次是文件夹1202的子文件夹。文件夹1201是根文件夹。根文件夹不是任何其它文件夹的子文件夹。所有其它文件夹都是以文件夹1201处为根的文件夹层次的成员。一般，文件夹层次中的每个文件夹对于每个其它文件夹没有直接关系。文件夹可能只对它的子文件夹有直接关系。文件夹也可以对把作为其子文件夹的任何文件夹具有直接关系。在许多情况中，可能只有每个文件夹都与之有直接关系的文件夹才是层次的根文件夹。
深层次表格可以包括有关文件夹层次中每个文件夹的信息。在深层次表格中，每个文件夹可以具有一个行。深层次表格中的信息是如此的，以致可以使用该信息来判定在特定时间期间的电子邮件文件夹的内容是否已经改变。可以使用在时间周期开始处取得的文件夹的行的拷贝与时间周期结束处取得的文件夹的行的拷贝进行简单的比较而执行在特定时间期间的电子邮件文件夹的改变的判定。在一个实施例中，深层次表格的每个行包括下列属性
任何时候当对文件夹的内容作出改变时，可以更新在深层次表格中的电子邮件文件夹的行的属性。为了有效实施深层次表格的更新，申请人已经发现具有对于深层次表格的快速和直接关系是有帮助的。至少，申请人已经发现当试图访问深层次表格时，应该有小的和可预测的间接级数。例如，在文件夹层次中的任意等级处定位的一个深层次表格将不提供可预测的间接级数。在本发明的一个实施例中，为了这个原因，深层次表格可以与电子邮件网络用户的电子邮件消息存储器文件夹层次的根文件夹相关联。
可以把电子邮件服务器部件和电子邮件用户部件之间的通信分割成通信会话。在会话之间可能发生电子邮件消息存储器同步的丢失，例如，在网络连接中断期间。为了在通信会话的开始处再建立电子邮件消息存储器同步，用于与以前版本电子邮件服务器部件通信的某些协议为文件夹层次中的每个文件夹使用Synchfolder ROP。一般，某些文件夹的内容在会话之间不会改变。具有未改变的文件夹作为目标的Synchfolder ROP导致“null synch”(零同步)。虽然“null synch”不会造成把任何文件夹改变传送给电子邮件用户部件，但是它还是具有与之相关联的额外开销，例如，可能是较大的一个状态区数据目标。
图13示出本发明的实施例，它了利用深层次表格避免产生这种“nullsynch”。在第一请求1301中，电子邮件用户部件501把请求深层次表格的ROP(例如，GetHierarchyTable)发送到电子邮件服务器部件502。在第一响应1302中，把深层次表格的拷贝提供给电子邮件用户部件501。一般，电子邮件用户部件501将具有前拷贝的深层次表格。电子邮件用户部件501可以通过对两份拷贝进行一行一行的比较而快速判定电子邮件服务器部件502上用户电子邮件消息存储器中的哪个文件夹已经改变。接着，使用ROP(例如，Synchfolder)以只对已经改变的那些文件夹进行同步。如需要的话可重复请求1303和响应1304使改变的文件夹同步。在同步成功之后，可以更新深层次表格的电子邮件用户部件的拷贝使之与响应1302中发送的最新拷贝相匹配。如果电子邮件用户部件501没有深层次表格的以前拷贝，则可以使具有最新拷贝一行的所有文件夹同步。
一旦已经建立用户的电子邮件消息存储器的同步，就可通过周期性地重复上述会话步骤的开始(例如，轮询)电子邮件服务器部件)来保持同步，但是这个方案具有缺点。例如，轮询周期可能比用户的电子邮件消息存储器改变之间的周期短得多。在该情况中，相当多的深层次表格比较将表示文件夹未经改变。实际上，这种比较是浪费力量，所以可以避免它们的一种协议可能是更有效的。
某些电子邮件网络包括一种用于电子邮件用户部件的设施，例如，当特定电子邮件文件夹的内容改变时向电子邮件服务器部件预约给予通知。某些以前版本电子邮件用户部件使用如此的设施，通过创建与用户文件夹层次中的每个文件夹相关联的改变通知的独立的预约，来保持用户电子邮件消息存储器的同步。在本发明的一个实施例中，电子邮件用户部件可以仅创建与深层次表格相关联的改变通知的单个预约。单个预约更为有效，因为需要较少的ROP来创建它以及服务器方面的资源消耗较少。
进一步参考图13，根据本发明的一个方面，当最新版本电子邮件用户部件501在与电子邮件服务器部件502的通信会话的开始处的第一请求1301中使用GetHierarchyTable ROP时，自动地使电子邮件用户部件501预约在响应1302中返回的、与深层次表格相关联的改变通知。例如，当在电子邮件用户部件处的用户电子邮件消息存储器中的电子邮件文件夹发生变化时，把电子邮件消息添加到文件夹中，还如上所述地也更新深层次表格。深层次表格的改变触发了给电子邮件用户部件501的通知报警1305。当根据预约由请求1301设置通知报警时，这不是明确的请求一响应周期的一部分。因此，使用本发明提供的通知系统导致电子邮件网络的额外开销小得多。
单个预约可以产生许多通知。在一个实施例中，使用无连接的网络传送机构，例如，用户数据报协议/因特网协议(UDP/IP)，来传送报警，但是可以使用任何合适的网络传送机构。响应于该报警，电子邮件用户部件501把包括ROP(例如，GetNotification)的请求1306发送给电子邮件服务器部件502。在响应1307中，把深层次表格的任何经改变的行(即，对应于触发通知的经改变的文件夹的行)发送到电子邮件用户部件501。然后电子邮件用户部件501使用ROP(例如，Synchfolder)而仅对已经改变的文件夹进行同步。
例如，多个电子邮件用户部件可以预约与相同数据目标(例如，相同文件夹)相关联的改变通知，以提供协作功能。如图18所示，电子邮件用户部件1801、1802和1803对于与位于电子邮件服务器部件1804处的相同数据目标(未示出)相关联的改变通知进行预约。电子邮件用户部件1803把ROP 1805发送给电子邮件服务器部件1804，形成数据目标的改变。作为改变的结果，电子邮件服务器部件1804把改变通知1806、1807和1808发送到电子邮件用户部件1801、1802和1803。例如，改变通知可以携带的信息很少超过正在识别的已改变的数据目标，以致电子邮件用户部件无法判定这是特定变化的起因。例如，如果数据目标是电子邮件文件夹，则改变通知1806、1807和1808可以导致每个电子邮件用户部件1801、1802和1803启动已改变文件夹的同步。由于在本例子中电子邮件用户部件1803是负责改变的，所以结果将是“null sych”(零同步)。
既于上面讨论的原因，希望排除产生“null sych”的同步。然而，所描述的通知行为不可能总是不需要的，而且某些电子邮件用户部件可能依赖它。本发明的一个方面是提供电子邮件用户部件有能力配置最新版本电子邮件服务器部件的通知行为，以便改进协议性能同时向以前版本电子邮件用户部件提供未改变的通知行为。
图19A描绘以前版本电子邮件服务器部件可以提供的通知行为。图19B描绘根据本发明的一个方面从可配置的通知行为。例如，在图19B中示出的例子中，如果需要，最新版本电子邮件用户部件可以通过提供带有请求的标志，IGNORE_OWN标志，来指挥能够进行图19B中的通知行为的电子邮件服务器部件。
在步骤1901处，选择要通知的签约用户组中的下一个候选者。在步骤1904处，检查签约的IGNORE_OWN标志。如果不存在标志，则步骤1904转移到步骤1902，在该步骤中，把通知发送给候选签约用户。如果找到标志，则步骤1904转移到步骤1905，在该步骤中，再次检查签约，判定是否签约用户触发这个通知。例如，可以通过检查用于设置签约的会话的通信会话识别符(“sessionID”)来作出这个判定。例如，sessionID可以包括全球性唯一识别符以及6字节串号。如果两者匹配，则通知将受抑。结果是引起通知的电子邮件用户部件将不能接收到该通知。然后子过程进行到步骤1903，如下所述。
如果签约用户没有触发通知，则与签约相关联的sessionID与同通知的起因相关联的sessionID不相同，步骤1905转移到步骤1902，在该步骤中，发送通知。然后过程进行到步骤1903，在该步骤中，作出是否有更多签约用户要通知的判定。如果有，则子过程返回到步骤1901，否则结束这个子过程。
如上所述，例如，利用电子邮件消息的高速缓冲存储器的电子邮件用户部件可以通过ROP来请求本地用户数据存储和电子邮件服务器部件处可得到的数据存储之间的消息或其它数据目标的同步。电子邮件用户部件可以同样请求从服务器存储器把要求消息拷贝到用户存储器。在任一种情况中，都可使用快速传送模式来作出请求。
一般，为了同步或拷贝而请求诸如文件之类的消息或其它数据时，请求(例如，ROP)包括所有消息要求同步的的指示。例如，电子邮件服务器部件利用上述状态区特征可以自动地构成这个列表。对于以前版本(以前技术)电子邮件服务器部件，在ROP请求中的一个消息或数据目标中的差错会导致请求中所有项目的失效。在图14A中示出这个过程，其中在步骤1401处用指定用于拷贝或同步的messageID(消息识别符)组来发送包括ROP(例如，FXPrepare)的一个请求。在电子邮件服务器部件502处设置快速传送机构，并在步骤1402处把快速传送ID(识别符)发送给电子邮件用户部件501。例如，然后电子邮件用户部件501通过包括FXGetBuffer ROP的一个请求来请求数据目标的拷贝或同步(步骤1403)。当电子邮件服务器部件502试图打开所请求的消息时，一个或多个消息或其它数据目标会发生差错。差错的例子包括消息或数据目标受到破坏、服务器失效、电子邮件服务器部件502缺少存储器或检测到数据目标的病毒。
在发生差错之后，在步骤1404处，电子邮件服务器部件502在形成的数据流中把致命的ROP差错发送给电子邮件用户部件501。这样，同步失败，对于messageID组中的消息不进行同步或拷贝，并且电子邮件用户部件501接收不到状态区或相似的更新信息。然后电子邮件用户部件501必须在另一个时间请求数据目标的同步或拷贝。如果差错不是固定在电子邮件服务器部件502处的，有可能继续发送差错消息，而messageID组中的消息可能永远不予同步或拷贝。
根据本发明的一个方面，最新版本电子邮件服务器部件可以发送关于特定数据目标(例如，电子邮件消息)的差错信息来代替致命的ROP差错，以致只有该数据目标同步失败。这个特征允许发送和同步或拷贝在ROP或其它请求中的消息或其它数据目标，即使在响应中包括具有差错的消息或其它数据目标。
作为如何处理目标一特定的差错的一个例子，最新版本电子邮件服务器部件可以在具有目标差错的数据目标的数据流中发送差错消息。在这个例子中，为了便于参考起见，把差错指定为FXErrorInfo。如下进一步描述，如果需要的话，FXErrorInfo可以包括诸如具有差错的数据目标的messageID之类的消息，以及关于消息为何失效的附加信息。
图14B示出一种同步，其中在消息M3中发生差错。差错产生在FXGetBuffe响应1405中，该响应包括消息M1和消息M2，后面跟随FXErrorInfo，然后是消息M4。FXErrorInfo信息允许电子邮件用户部件501知道哪个消息具有差错，并且对响应中的所有其它消息进行同步。如果差错消息FXErrorInfo包括有关差错原因的信息，则相应地可以使信息在用户部件上起作用，例如，向用户显示差错消息。
下面表格示出FXErrorInfo可以采用的格式的例子
可以看到，示例格式包括版本属性、差错代码以及messageID。此外，如果需要的话，可以添加一个或多个属性。此外，如上所述，可以定义用于传送差错细节的辅助字段，这样，可以定义用于确定差错细节的字段大小(例如，一个阵列)的属性，并且可以提供一个字段，例如，这个字段可以是用于传送差错细节的未构成的阵列。如上所述，电子邮件用户部件501可以按要求处理差错细节。
FXErrorInfo允许完成第一响应的同步，例如，在提供给电子邮件用户部件501的状态区或其它信息中产生的。因为现在电子邮件用户部件是通过M4来同步的，所以用于同步的下一个请求1406可在M4之后(例如，M5和M6)形成于具有消息的响应1407中。
为了指示电子邮件用户部件501是最新版本，因此能够处理FXErrorInfo消息，例如，可以定义一个标志FXRecoverMode，这可以与请求同步或拷贝的ROP一起发送。电子邮件用户部件501可以使用其它指示来向电子邮件服务器部件502传送它能处理的FXErrorInfo消息。
当电子邮件服务器部件502把一个或多个消息或其它数据目标发送给电子邮件用户部件501时，到电子邮件用户部件的数据流可以分开，或通过特性标记(例如，ptag)来定义。例如，消息列表可以包括每个消息的开始消息ptag和结束消息ptag。在开始和结束ptag之间可以是特性列表ptag和主题ptag，它们可以具有字符串的特性。主题本身跟随主题ptag。可以包括其它特性tags。
在发送消息中发生差错的情况中，可以提供FXErrorInfo作为ptag，并且可以具有二进制特性，诸如是通过上述表格定义的。数据流跟随一个成功的消息和一个有差错发生在其中的消息的一个例子。在发生差错的情况中，不使用该特定消息的结束消息ptag，而ptag FXErrorInfo是该消息的最后ptag。
ptagMessageListStartptagMessageStartptagPropListptagSubj ect[PT_STRING]“备注你的电子邮件”...
ptagMessageEndptageMessageStart
...
ptagFXErrorInfo[PT_BINARY][内容如表格所描述]ptagMessageStart...
ptagMessageEndptagMessageListEnd图15A示出一些步骤，电子邮件服务器部件502可以利用这些步骤把消息传送到以前版本电子邮件用户部件501。在步骤1501处开始，例如，通过把消息组放置在快速传送数据存储器中而准备消息组。在步骤1502处，例如，当消息紧接置于在电子邮件服务器部件502的发送缓冲器中之后，消息就开始形成流式输出。如果当流式输出消息时发生差错，则在步骤1504中，使致命的ROP差错也以流式输出到电子邮件用户部件501。然后子过程结束。如果在流式输出消息时，没有发生差错，则在步骤1503处作出组中是否有更多消息的判定。如果有，则过程回路返回步骤1502，在该步骤中，把下一个消息形成流式输出。如果没有，则子过程结束。
图15B示出一个过程，用于由最新版本电子邮件服务器部件502来处理消息组。根据电子邮件用户部件是最新版本还是以前版本，所采用的步骤是不同的。步骤1501-1504是以前版本电子邮件用户部件采用的步骤，并且与前面段落中相同参考号的那些步骤相同。
在步骤1502处，如果在消息流中发现差错，则在步骤1505处作出请求是否包括诸如FXRecoverMode之类的标志的判定。如果请求包括标志，则电子邮件用户部件501是最新版本，并且步骤1505转移到步骤1506，在该步骤中，把FXErrorInfo形成流式输出到电子邮件用户部件501。然后过程可以继续进行到步骤1503。如果请求不包括标志，则步骤1505转移到步骤1504，在该步骤中，使致命的ROP差错作为流输出。然后结束子过程。
可以看到，在请求中出现标志，则允许通过流式输出FXErrorInfo来代替失效和发送致命的ROP差错，从而继续进行流式过程。最新版本电子邮件用户部件501发送所述标志。以前版本电子邮件用户部件不包括标志，因此，差错导致流式输出致命的ROP差错，如上所述。
在另一个实施例中，如果需要，可以发送消息或其它数据目标的特定特性的差错消息(例如，FXErrorInfo)来代替整个消息。例如，可以为消息的主体或为消息的附件发送FXErrorInfo。然后电子邮件用户部件501可以同步或拷贝无差错地成功地发送的特性，并且只有具有差错的特性不进行同步或拷贝。
某些时候，消息或其它数据目标可以是跨越多个FXGetBuffe响应的足够大小。为了处理这种消息，电子邮件用户部件501可以包括卷回逻辑，以致在接收差错消息之后，它可以放下任何接收到的部分消息，然后进行合适地接收进一步消息。
有时，可能要求电子邮件用户部件提供关于诸如电子邮件消息之类数据目标的拷贝和同步的进展的反馈。根据本发明的一个方面，最新版本电子邮件用户部件501可以确定它能够处理进展模式，例如，当请求数据目标的同步或拷贝时，通过把诸如PROGRESS_MODE之类的一个标志发送给电子邮件服务器部件502。作为响应，最新版本电子邮件服务器部件502可以与消息一起发送多种信息，诸如所有消息的总的大小、消息的总数以及每个消息的总的大小或这些中的任何一个或它们的组合。
例如，如在图16A中所示，对于以前版本电子邮件用户部件501，电子邮件用户部件501根据消息组的快速传送请求(1601和1603)来接收消息。在图16A中，在两个响应1604和1606中接收消息。在使用快速传送机构的以前版本电子邮件用户部件501中，不提供正在流式输出到用户的消息的进展指示。
然而，如在图16B中所示，响应1607是对于电子邮件用户部件的消息组的请求的，电子邮件服务器部件502可以提供要传送的数据目标的总数以及所有数据目标的总的大小。在图16中用“Pall”来表示这个信息。最新版本电子邮件服务器部件502还可以提供每个消息的大小，在图16B中用“P1，P2，P3，...”来表示。此外，如果需要的话，与每个消息和与整个消息组相关联的信息可以包括有关每个消息是FAI还是实际电子邮件消息的附加信息。在一个实施例中，即使传送零个数据目标，在图16B中通过“Pall”表示的信息也始终响应于快速传送请求而发送，以便简化数据流的处理。
在下列表格中示出所传送的所有数据目标的大小和数量的格式的例子。
可以看到，对于FAI数据目标的数量、所有FAI数据目标的总的大小、要传送的电子邮件消息的数量以及要传送的所有电子邮件消息的总的大小可以定义独立的属性。可以按需要把其它组合和附加属性添加到格式中。
下面表格示出用于大小和可以与每个消息一起提供的其它信息的一种格式。
可以看到，格式包括下一个消息的大小以及下一个消息是否为FAI。
图17A和17B示出一些步骤，用于分别根据以前版本电子邮件部件和最新版本电子邮件部件使消息组形成流。图17A中的步骤与图15A中的步骤1501-1503相似。对于图17B，例如，已经由最新版本电子邮件用户部件501与发送了带有ROP的PROGRESS_MODE标志。在步骤1701处准备消息组之后，作出标志是否存在的判定。如果存在的话，则在步骤1702中发送进展数据总数，然后过程进行到步骤1502，在该步骤中，使第一消息形成流。如果不存在标志，则步骤1701直接转移到步骤1502。
在使第一消息形成流之后，过程进行到步骤1703，在该步骤中，作出是否可得到标志的判定。如果可得到标志，则步骤1703转移到步骤1704，在该步骤中，使每个消息进展数据形成流。然后过程进行到早先描述的步骤1503。如果未得到标志，则步骤1703直接转移到步骤1503。
下面陈述最新服务器部件把数据发送到最新用户部件的数据流的例子。数据流相似于上述数据流，但是另外包括，例如，可以具有二进制特性的进展总数据的ptag(ptagIncrSyncProgressMode)。此外，对于每个消息，提供每消息进展数据，例如作为ptagIncrSyncProgressModePerMsg。
ptagIncrSyncProgressMode [PT_BINARY][内容如表格所描述]ptagMessageListStartptagIncrSyncProgressModePerMsg [PT_BINARY][内容如表格所描述]ptagMessageStartptagPropListptagSubject [PT_STRING]“备注你的电子邮件”...
ptagMessageEndptagIncrSyncProgressModePerMsg [PT_BINARY][内容如表格所描述]ptagMessageStart...
ptagMessageEndptagIncrSyncProgressModePerMsg [PT_BINARY][内容如表格所描述]
ptagMessageStart...
ptagMessageEndptagMessageListEnd在所示的例子中，在消息列表之前以及在每个消息之前，分别对包括进展总数据(ptagIncrSyncProgressMode)的ptag以及消息进展数据(ptagIncrSyncProgressModePerMsg)的ptag进行定位。然而，可以使数据目标的流的结构反向，以致可以把进展数据包括在消息中或消息列表中。又可能使数据目标的流的结构反向，以便完全消除限定消息和/或消息列表的ptag。
接收进展数据的电子邮件用户部件可以利用这个数据来确定来自电子邮件服务器部件的数据目标的同步或拷贝的进展，以及可以利用每消息进展数据来确定每个独立的消息的进展。例如，在监测关于同步的进展的实时信息中，这个信息是有帮助的。
现有可以用来存储电子邮件消息或其它数据目标的数个不同的字符组。例如，ASCII是最普遍用于存储英语字符的。然而，对于存储所有语言的字符，ASCII是不够的，因为它是基于8-位字符的。因此，ASCII代码只可以用于256个字符，这对于英语是足够的，但是对于有更多字符的语言是不够的。另一方面，单码(unicode)是每个字符使用16位(2字节)的字符组，因此能够包括比ASCII多的字符。单码可以有65,536个字符，因此可以用于对世界上几乎所有的语言进行编码。在单码中包括ASCII字符。
一般，以前版本电子邮件用户部件501具有指定的代码页，或字符组和/或与之相关联的语言。例如，特定版本的电子邮件用户部件501可以具有德文代码页，而另一个版本可以具有ANSI代码页。有时，可能要求电子邮件用户部件501接收字符组中的电子邮件而不是指定的代码页。根据本发明的一个方面，最新用户部件可以强制电子邮件服务器部件提供按单码的所有电子邮件。一旦电子邮件用户部件501接收电子邮件，就可以把单码电子邮件转换成用户的代码页，或另一方面，可以按单码格式来保存。
为了确定电子邮件用户部件501调用按单码提供的电子邮件，例如，电子邮件用户部件501可以把诸如FORCEUNICODE之类的标志提供给电子邮件服务器部件502。标志可以与诸如ROP之类的请求一起提供。如果电子邮件服务器部件502是最新版本的，则电子邮件服务器部件502可以提供单码版本的电子邮件(如果可得到的话)，或可以按其它字符组把电子邮件消息转换成单码。
图20示出一些步骤，用于根据本发明的一个方面提供消息的特定字符组。在步骤2001处开始，电子邮件服务器部件502从它的数据存储器检索消息。在步骤2002处，作出是否存在FORCEUNICODE标志的判定。如果不存在，则步骤2002转移到步骤2003，在该步骤中，电子邮件服务器部件502提供按电子邮件用户部件指定的代码页的电子邮件消息，如果需要的话，则进行转换。
如果存在FORCEUNICODE标志，则步骤2002转移到步骤2004，在该步骤中，作出消息是否按单码存储的判定。如果是的，则步骤2004转移到步骤2005，在该步骤中，按单码字符组把消息提供给电子邮件用户部件501。如果消息没有按单码存储，则步骤2004转移到步骤2006，在该步骤中，把消息转换成单码，然后过程继续进行到步骤2005，在该步骤中，按单码把消息提供给电子邮件用户部件。
从而为了完整性而结合这里引用的、包括公开出版物、专利申请以及专利等的所有参考资料引入于此作参考，其参考程度又似各参考资料可单独地和特定地确定加以引入作为参考和所有这些参考资料作为一个整体来加以表示。
除非这里另行规定或通过上下文清楚地否认，在描述本发明的上下文中(特别在下面权利要求书的上下文中)，把术语“a(一个)”和“an(一个)”和“the(该)”以及相似指示物的使用解释为包括单数和复数两者。除非另行注明，术语“comprising(包括)”、“having(具有)”、“including(包括)”、以及“containing(包含)”解释为无尽头的术语(即，意思为“包括，但是不限于，”)。除非这里另行规定，只打算把这里详述的值的范围作为一种简化方法，以个别地涉及落在范围中的每个独立值，并好象在这里对其个别进行详述那样把每个独立值引入在说明书中。除非这里另行规定或通过上下文清楚地相抵触，可以按任何合适的次序来执行这里描述的所有方法。只打算以这里提供的任何或所有例子、或示例语言(例如，“诸如”)的使用来较好地阐明本发明，不造成对于本发明的范围的限制，并且除非另行要求。对于本发明实践的基本部分，本说明书中没有语言该解释为指出的任何非专利申请部分。
这里描述了本发明的较佳实施例，包括发明人已知的执行本发明的最佳模式。当阅读上述说明书时，熟悉本技术领域的人员会明白这些较佳实施例的改变。发明人期望熟练的技术人员适当地使用这种改变，并且发明人设想不同于这里的特别描述而实践本发明。因此，象可应用的法律所允许那样，本发明包括在这里所附的权利要求书中引用的主题的所有修改和等效物。此外，除非这里另行规定或另外通过上下文清楚地相抵触，本发明包括在所有可能改变中的上述单元的任何组合。
权利要求
1.包含在计算机可读出媒体中的一种数据分组包括识别电子邮件用户部件的第一数据字段；包括对于多个电子邮件数据目标的一个请求的第二数据字段；以及包括电子邮件用户部件能够处理有差错的电子邮件数据目标的一个指示的第三数据字段。
2.如权利要求1所述的数据分组，其特征在于，所述指示包括与请求包括在一起的一个标志。
3.如权利要求1所述的数据分组，其特征在于，所述请求包括用于同步文件夹的一个请求，在所述文件夹中设置有电子邮件数据目标。
4.如权利要求1所述的数据分组，其特征在于，所述请求包括对于电子邮件消息的拷贝的一个请求。
5.具有计算机可执行指令的一种计算机可读出媒体，所述指令包括从电子邮件用户部件接收用于多个电子邮件数据目标的一个请求以及所述电子邮件用户部件能够处理有差错的电子邮件数据目标的一个指示；以及响应于所述请求和所述指示，检索多个电子邮件数据目标；以及对于各个电子邮件数据目标如果在打开电子邮件数据目标中没有发生差错，则把电子邮件数据目标发送给电子邮件用户部件，以及如果在打开电子邮件数据目标中发生差错，则把差错消息发送给电子邮件用户部件。
6.如权利要求5所述的计算机可读出媒体，其特征在于，所述差错消息包括电子邮件数据目标的版本信息。
7.如权利要求6所述的计算机可读出媒体，其特征在于，所述版本信息包括16位整数。
8.如权利要求5所述的计算机可读出媒体，其特征在于，所述差错消息包括电子邮件数据目标的识别信息。
9.如权利要求8所述的计算机可读出媒体，其特征在于，所述识别信息包括32位整数。
10.如权利要求8所述的计算机可读出媒体，其特征在于，所述识别信息包括全球性唯一的识别符(GUID)以及6字节串号。
11.如权利要求5所述的计算机可读出媒体，其特征在于，所述差错消息包括有关差错的信息。
12.如权利要求11所述的计算机可读出媒体，其特征在于，所述有关差错的信息包括用于传递差错细节的阵列的大小。
13.如权利要求5所述的计算机可读出媒体，其特征在于，所述指示包括与所述请求包括在一起的一个标志。
14.如权利要求5所述的计算机可读出媒体，其特征在于，所述请求包括1个有电子邮件数据目标设置在其中的文件夹同步的请求。
15.如权利要求5所述的计算机可读出媒体，其特征在于，所述请求包括对于电子邮件消息的拷贝的一个请求。
16.具有计算机可执行指令的一种计算机可读出媒体，所述指令包括从电子邮件用户部件发送用于多个电子邮件数据目标的一个请求以及所述电子邮件用户部件能够处理有差错的电子邮件数据目标的一个指示；以及对于每个电子邮件数据目标如果电子邮件数据目标不包含差错，则在电子邮件用户部件处接收电子邮件数据目标和拷贝电子邮件数据目标，以及如果电子邮件数据目标包含差错，则接收差错消息。
17.如权利要求16所述的计算机可读出媒体，其特征在于，所述差错消息包括对于电子邮件数据目标的识别。
18.如权利要求16所述的计算机可读出媒体，其特征在于，所述差错消息包括有关差错的信息。
19.如权利要求16所述的计算机可读出媒体，其特征在于，所述差错消息包括与所述请求包括在一起的一个标志。
20.如权利要求16所述的计算机可读出媒体，其特征在于，所述请求包括1个有电子邮件数据目标设置在其中的文件夹同步的请求。
21.如权利要求16所述的计算机可读出媒体，其特征在于，所述请求包括对于电子邮件消息的拷贝的一个请求。
22.包含在计算机可读出媒体中的一种数据分组包括识别有关电子邮件数据目标的识别信息的第一数据字段；以及包括电子邮件数据目标的差错代码的第二数据字段。
23.如权利要求22所述的数据分组，进一步包括表示所述电子邮件数据目标的版本信息的第三数据字段。
24.如权利要求23所述的数据分组，其特征在于，所述第三数据字段包括16位整数。
25.如权利要求22所述的数据分组，进一步包括表示电子邮件数据目标的识别信息的第三数据字段。
26.如权利要求25所述的数据分组，其特征在于，所述第三数据字段包括32位整数。
27.如权利要求25所述的数据分组，其特征在于，所述第三数据字段包括全球性唯一的识别符(GUID)以及6字节串号。
28.如权利要求22所述的数据分组，进一步包括有关差错的信息的第三数据字段，所述差错是与差错代码相关的。
29.如权利要求28所述的数据分组，其特征在于，所述有关差错的信息包括用于传递差错细节的阵列的大小。
30.包含于计算机可读出媒体中的一种数据分组包括识别电子邮件用户部件的第一数据字段；包括对于多个电子邮件数据目标的一个请求的第二数据字段；以及包括电子邮件用户部件能够处理进展模式数据的一个指示的第三数据字段。
31.如权利要求30所述的数据分组，其特征在于，所述进展模式数据包括每个电子邮件数据目标的大小。
32.如权利要求30所述的数据分组，其特征在于，所述指示包括与请求包括在一起的一个标志。
33.如权利要求30所述的数据分组，其特征在于，所述请求包括1个有电子邮件数据目标设置在其中的文件夹同步的请求。
34.如权利要求30所述的数据分组，其特征在于，所述请求包括对于电子邮件消息的拷贝的一个请求。
35.如权利要求30所述的数据分组，其特征在于，所述进展模式数据包括多个数据目标的大小。
36.如权利要求30所述的数据分组，其特征在于，所述进展模式数据包括多个电子邮件数据目标中文件夹相关联信息(FAI)目标的数量。
37.如权利要求36所述的数据分组，其特征在于，所述进展模式数据包括在多个电子邮件数据目标中完全的文件夹相关联信息(FAI)目标的大小。
38.如权利要求30所述的数据分组，其特征在于，所述进展模式数据包括多个电子邮件数据目标中的电子邮件消息的数量。
39.如权利要求38所述的数据分组，其特征在于，所述进展模式数据包括多个电子邮件数据目标中的总的电子邮件消息的大小。
40.如权利要求30所述的数据分组，其特征在于，所述进展模式数据进一步包括是否每个目标都是文件夹相关联信息(FAI)目标。
41.具有计算机可执行指令的一种计算机可读出媒体，所述指令包括从电子邮件用户部件接收用于多个电子邮件数据目标的一个请求以及所述电子邮件用户部件能够处理进展模式数据的一个指示；以及响应于所述请求和所述指示，检索多个电子邮件数据目标；以及把进展模式数据与多个数据目标一起提供给电子邮件用户部件，所述进展模式数据包括每个电子邮件数据目标的大小。
42.如权利要求41所述的计算机可读出媒体，其特征在于，所述指示包括与请求包括在一起的一个标志。
43.如权利要求41所述的计算机可读出媒体，其特征在于，所述请求包括一个有电子邮件数据目标设置在其中的文件夹同步的请求。
44.如权利要求41所述的计算机可读出媒体，其特征在于，所述请求包括对于电子邮件消息的拷贝的一个请求。
45.如权利要求41所述的计算机可读出媒体，其特征在于，所述进展模式数据进一步包括多个数据目标的大小。
46.如权利要求41所述的计算机可读出媒体，其特征在于，所述进展模式数据进一步包括在多个数据目标中的文件夹相关联信息(FAI)目标的数量。
47.如权利要求46所述的计算机可读出媒体，其特征在于，所述进展模式数据进一步包括在多个数据目标中的总的文件夹相关联信息(FAI)目标的大小。
48.如权利要求41所述的计算机可读出媒体，其特征在于，所述进展模式数据进一步包括多个电子邮件数据目标中的电子邮件消息的数量。
49.如权利要求48所述的计算机可读出媒体，其特征在于，所述进展模式数据进一步包括多个电子邮件数据目标中的总的电子邮件消息的大小。
50.如权利要求41所述的计算机可读出媒体，其特征在于，所述进展模式数据进一步包括是否每个目标都是文件夹相关联信息(FAI)目标。
51.具有计算机可执行指令的一种计算机可读出媒体，所述指令包括从电子邮件用户部件接收用于多个电子邮件数据目标的一个请求以及所述电子邮件用户部件能够处理进展模式数据的一个指示；以及响应于所述请求和所述指示，检索多个电子邮件数据目标；以及把进展模式数据与多个数据目标一起提供给电子邮件用户部件，所述进展模式数据包括多个电子邮件数据目标的大小。
52.如权利要求51所述的计算机可读出媒体，其特征在于，所述指示包括与请求包括在一起的一个标志。
53.如权利要求51所述的计算机可读出媒体，其特征在于，所述请求包括一个用有电子邮件数据目标设置在其中的文件夹同步的请求。
54.如权利要求51所述的计算机可读出媒体，其特征在于，所述请求包括对于电子邮件消息的拷贝的一个请求。
55.如权利要求51所述的计算机可读出媒体，其特征在于，所述进展模式数据进一步包括多个数据目标中每一个数据目标的大小。
56.如权利要求51所述的计算机可读出媒体，其特征在于，所述进展模式数据进一步包括在多个数据目标中的文件夹相关联信息(FAI)目标的数量。
57.如权利要求56所述的计算机可读出媒体，其特征在于，所述进展模式数据进一步包括在多个数据目标中的总的文件夹相关联信息(FAI)目标的大小。
58.如权利要求51所述的计算机可读出媒体，其特征在于，所述进展模式数据进一步包括多个电子邮件数据目标中的电子邮件消息的数量。
59.如权利要求58所述的计算机可读出媒体，其特征在于，所述进展模式数据进一步包括多个电子邮件数据目标中的总的电子邮件消息的大小。
60.如权利要求51所述的计算机可读出媒体，其特征在于，所述进展模式数据进一步包括是否每个目标都是文件夹相关联信息(FAI)目标。
61.一种计算机执行的方法包括从电子邮件用户部件发送用于多个电子邮件数据目标的一个请求以及所述电子邮件用户部件能够处理进展模式数据的一个指示；以及在电子邮件服务器部件处，响应于所述请求和所述指示，检索多个电子邮件数据目标和多个电子邮件数据目标的进展模式数据；以及在电子邮件用户部件处，接收进展模式数据和利用所述进展模式数据来监测多个数据目标到电子邮件用户部件的发送进展。
62.如权利要求61所述的方法，其特征在于，所述进展模式数据包括多个电子邮件数据目标的大小。
63.如权利要求61所述的方法，其特征在于，所述进展模式数据包括多个数据目标中每一个数据目标的大小。
64.如权利要求61所述的方法，其特征在于，所述进展模式数据包括在多个数据目标中的文件夹相关联信息(FAI)目标的数量。
65.如权利要求64所述的方法，其特征在于，所述进展模式数据包括在多个数据目标中的总的文件夹相关联信息(FAI)目标的大小。
66.如权利要求61所述的方法，其特征在于，所述进展模式数据包括多个电子邮件数据目标中的电子邮件消息的数量。
67.如权利要求66所述的方法，其特征在于，所述进展模式数据包括多个电子邮件数据目标中的总的电子邮件消息的大小。
68.如权利要求61所述的方法，其特征在于，所述进展模式数据进一步包括是否每个目标都是文件夹相关联信息(FAI)目标。
69.具有计算机可执行指令的一种计算机可读出媒体，所述指令包括从电子邮件用户部件接收请求中的多个子请求，每个子请求请求电子邮件服务器部件处的一个操作，以及包括大小信息；以及响应于每个子请求如果大小信息包括电子邮件服务器部件预期范围内的大小极限，则把响应限制于大小极限；以及如果大小信息包括电子邮件服务器部件预期范围之外的大小极限，则在大小信息中寻找新的大小极限。
70.如权利要求69所述的计算机可读出媒体，进一步包括，如果大小信息包括电子邮件服务器部件预期范围之外的大小极限，则利用响应填充电子邮件服务器部件的缓冲器。
71.一种计算机执行的方法包括在电子邮件用户部件处创建请求中的多个子请求，每个子请求在电子邮件服务器部件处请求一次操作，以及包括大小信息；以及把请求发送给电子邮件服务器部件；在电子邮件服务器部件处接收请求；以及响应于每个子请求如果大小信息包括电子邮件服务器部件预期范围内的大小极限，则把响应限制于大小极限；以及如果大小信息包括电子邮件服务器部件预期范围之外的大小极限，则在大小信息中寻找新的大小极限。
72.如权利要求71所述的方法，进一步包括，如果大小信息包括电子邮件服务器部件预期范围之外的大小极限，则利用响应填充电子邮件服务器部件的缓冲器。
全文摘要
改进用户和服务器通信的一种系统和方法，尤其，可以在诸如电子邮件环境之类的用户和服务器之间的通信中使用的一种改进的协议。在改进通信中规定有许多特征。电子邮件服务器可以为电子邮件消息提供最佳消息主体，如果在数据目标中没有较好地定义所请求的一个特性或一些特性，则可以传送整个数据目标，可以提供用于跟踪下载进程的进展数据，以及可以发送有差错的数据目标的差错信息。电子邮件改变在电子邮件服务器部件处可得以最优化，即使在另一个电子邮件服务器部件处发生电子邮件改变。电子邮件服务器可以把发生于文件夹中的改变表格保存在相关联的数据存储器中，以及可以把发生在表格中的改变通知签约的电子邮件用户部件。
文档编号H04L12/58GK1518304SQ20031012455
公开日2004年8月4日 申请日期2003年12月31日 优先权日2003年1月3日
发明者J·R·沃仁, M·钟, K·弗罗伊利奇, N·A·包尼拉, R·R·诺维特斯基, A·顿, R·E·格雷, A·哈特维尔, S·F·格得达得, B·包威尔, J R 沃仁, 包尼拉, 匚 , 抟晾 , 格得达得, 格雷, 诺维特斯基 申请人:微软公司