updates.txt

Delphi快速开发Web Server

All data will (from this version on) be sent using mixed case field names, preserving the original 
"casing" when sending records/functions/datasets. This is especially useful for Field Names in datasets,
but could also be useful when sending any other data. Because of this change in behavior, RTC Servers 
and RTC Clients compiled using RTC SDK versions prior to 2.04 (2.0 RC 4) will NOT be able to work 
with RTC Clients and Servers built using this latest RTC SDK release, because the old 
implementation for remote functions is expecting all field names to come in uppercase and 
this will no longer be true with this latest RTC SDK release.

The new RTC SDK can handle new and old clients/servers without any problems and there are now changes 
required in your code, all the functionality remains the same (you can still use different case names),
but the old RTC SDK will not be able to handle remote function calls if they come with mixed-case field names.

In other words, if you are still using clients compiled with RTC SDK 1.9 or older, if you can not
upgrade all your clients and the Server "at once", I would suggest that you start by upgrading the 
Server to the RTC SDK 2.19 (or any other version after 2.04) which is still available for download, 
then you can upgrade all the clients to RTC SDK 2.20 (or the current latest release). Only after all 
your clients have been upgdraded to the RTC SDK 2.20 (or later), you can also upgrade the Server 
to the latest RTC SDK release (currently 2.20).

Here is what has changed (in more detail) ...

1) Performance dupdate for working with RTC objects using field names:

   In prior versions, all field names were stored in a TStringList which had to be scanned
   from top to bottom for each field access (using field name), because I wanted to preserve 
   the original field order (fields were sent in the same order they were created).

   For the case-insensitive "indexing" to work, all field names had to be converted to UpperCase,
   or a Case-Insensitiv option had to be enabled for the internal TStringList (making the search slower).

   Now, mixed case names are preserved (stored in the TStringList in their original order) and a 
   separate binary search tree is used to store uppercase versions of all field names (with their indexes), 
   which is then used for fast searching (the more fields, the higher performance improvement).

   Case-insensitive search now works without losing the original mixed case format and all searching 
   is done using a binary search tree, which is extremely fast, especially when compared to the 
   sequential scan method used in the prior version.

2) HTTP headers and Remote function parameters will now be sent using the same mixed case which
   was used to prepare them. In other words, you will now get the exact Field Names on "the other side",
   which you used to store the data in records, function parameters, datasets and HTTP headers.
   There will be no more automatic capitalization done. All to uppercase? No, thanks! :)


---------------------------------------------------------
* RTC SDK 2.19
---------------------------------------------------------

1) Updated the WebPackageManager, WebForum and WebServer2 Demos to compile with Delphi 4, 5 and 6.

2) Moved WebPackageManager, WebForum, WebForum_ISAPI, WebServer2 and WebServer_TLS projects to
   the "deploy" folder, to make it possible to debug the projects in Delphi 4. There is a bug in 
   Delphi 4 which makes it impossible to debug applications compiled to a location different from
   the default exe location (Delphi can not find the EXE after compilation).

3) Added rtcSDK_C4.bpk package for installing the RTC SDK in BCB 4.

---------------------------------------------------------
* RTC SDK 2.18
---------------------------------------------------------

1) Updated the License Agreement to correct contradicting wording which could lead to 
   a misconception that deployment of ISAPI extensions (Dynamic Link Libraries) was 
   prohibited under the commercial license agreement, which would be nonsense, 
   since the RealThinClient SDK is also designed for writing ISAPI extensions.

   Please see the "License.txt" file for the updated License Agreement.

2) Corrected a few QuickStart examples. 
   Now all QuickStart examples compile with Delphi 4 and above.

---------------------------------------------------------
* RTC SDK 2.17
---------------------------------------------------------

1) Added TRtcDualDataServerLink component: 

This component can be used to link the same Data Provider components to multiple Server 
connection components (for example, HTTP Server, HTTPS server, NexusDB transport, direct link, etc).
This is useful if you want to serve your content over multiple transports, without having to compile 
the code into a separate exe, so that session information is accessible over multiple servers.

2) Moved units "rtcPHP", "rtcPHPTypes" and "rtcISAPI" from the "Lib" folder to "Demos/DataProvider".
   This is to reflect the fact that those are only examples for running PHP scripts and executing
   ISAPI extensions from a RTC WebServer, but are not part of the RTC SDK library as such. 
   So, those units are still there, just not in the "Lib" folder anymore.

3) Removed the "rtcISAPI" and "rtcPHP" units from all RTC SDK packages,
   since there are no components in these files and the files are not 
   required to compile the RealThinClient SDK components. 

---------------------------------------------------------
* RTC SDK 2.16
---------------------------------------------------------

Components have been stress-tested and new Help files were generated.

---------------------------------------------------------
* RTC SDK 2.0 - RC 16 (stable)
---------------------------------------------------------

***Fix***

1) Changed the "IRTCThreadCallback" interface to a "TRtcThreadCallback" class.

2) Changed implementation in "rtcActiveX" to extend the "TRtcThreadCallback" class instead of extending TComponent and implementing the IRTCThreadCallback interface.

---------------------------------------------------------
* RTC SDK 2.0 - RC 15
---------------------------------------------------------

***Update***

1) Added "IRTCThreadCallback" interface, which can be used to add special 
   thread initialization and uninitialization code for the stand-alone RTC Server.

2) Added "rtcActiveX" unit, which you can include ("uses") in your project if 
   you are using ADO components in a multithreaded client/server and need each 
   thread to call CoInitialize on thread start and CoUninitialize before thread "stop".

3) Added "rtcDBTypes" unit, which includes arrays for converting RTC Field Types to 
   standard Delphi Field Types (TDataSet), as well as a simple impementation of functions
   for copying data from a RTC DataSet to a TDataSet and vice versa.

4) A new QuickStart example for using the RTC Parser (rtcParse3.dpr)

---------------------------------------------------------
* RTC SDK 2.0 beta - RC 14
---------------------------------------------------------

***Update***

1) Constructors with Values as parameters for all TRtcSimpleValueObject classes (TRtcInveterValue, TRtcStringValue, TRtcBooleanValue, etc). Those new constructors will be useful if you need to convert data stored in some other containers (for example, COM data types) into RTC objects.

2) Added method TRtcDataSet.SetField(FldName:string; FldType:TRtcFieldTypes; FldSize:integer=0; FldRequired:boolean=False); - Now you can define fields in a RTC DataSet using a single method call. This call is equivalend to assigning the values to FieldType, FieldSize and FieldRequired properties.

3) Mime_Encode and Mime_Decode functions (for base64 string encoding and decoding) are now available for public use (unit "rtcInfo"). Those functions are not required for things related to the RTC SDK, but since we now have XML-RPC support and some clients or servers could be sending you Mime Encoded data where data should be sent in plain strings, you now have functions to encode and decode the data if necessary.


---------------------------------------------------------
* RTC SDK 2.0 beta - RC 13
---------------------------------------------------------

***Update***

1) Added support for different Session locking options:
  - sesIPLock (this was the only option until now)
  - sesFwdLock (this is the new default)
  - sesIPFwdLock
  - sesNoLock 

1a) sesNoLock: Allow access to anyone. No client data will be used for identifying clients, which means that any client knowing which Session IDs are open, will have access to those sessions, regardless of its IP address or other header values. This setting is not recommended for Servers available on the Internet.

1b) sesIPLock: Allow access to an opened Session only to Clients coming from the same IP as the client which has created the session. This setting is not recommended for Web Applications which need to be accessible by anyone, since people behind proxy servers with changing IP addresses will not be able to "stay logged in" (when their IP changes, they will lose access to their Session).

1c) sesFwdLock: This is the default Session Lock setting, which should work for all clients. It will provide maximum security for clients which are NOT behind a proxy server, while still allowing access to clients behind proxy servers with changing IP addresses (the "X-FORWARDED-FOR" header has to be set by the proxy forwarding client requests). 

If the client opening the Session had the "X-FORWARDED-FOR" header set, any client with the same "X-FORWARDED-FOR" header will be allowed access to his Session (it just has to use the same Session ID as the client which has opened/created the session). If "X-FORWARDER-FOR" header was not set by the client creating the session, Peer IP address will be used for client identification.

1d) sesIPFwdLock: Session will always be locked to the Peer IP address, *plus* to the "X-FORWARDED-FOR" request header, if it was set for the client which has opened the session. This setting is not recommended for Web Applications which need to be accessible to a wide public audience, since people behind proxy servers with changing IP addresses will NOT be able to "stay logged in". When their IP address changes, they will lose access to their Session data and need to log in again.

2) Added new property "AutoSessionsLock" to the TRtcServerModule component, which you can use to define which Session Locking mode you want to use for Sessions created automaticaly by this rtcServerModule component for use with remote functions. Unless you have some special requirements (more or less session security), you should leave the settings at default (sesFwdLock).

3) The "OpenSession" method in the TRtcDataServer component (available to all descendant components like TRtcHttpServer and TRtcISAPIServer) now has an *optional* parameter "LockType", which defaults to "sesFwdLock". Unless you need to use a different session locking mechanism (with more or less security for the clients), you should continue using the OpenSession method without parameters.


---------------------------------------------------------
* RTC SDK 2.0 beta - RC 12
---------------------------------------------------------

***Update***

1) Added RTC SDK 2.0 Help files for BDS 2006 (BDS 4.0)

2) Added support for sending files using a "FileStream" implementation (TRtcFileStream),
   which keeps the file open until it was sent out or client disconnects, slightly 
   increasing performance when sending large files.
  * disabled by default

3) Added a new variable to allow forcing the OnDataSent event to be triggered even when 
   WinSock buffers are full, to prepare new data and have something to send out once 
   buffers are empty. This can increase performance when sending large files out.
  * disabled by default


---------------------------------------------------------
* RTC SDK 2.0 beta - RC 11
---------------------------------------------------------

***Update***

1) Additional handling of non-standard XML-RPC strings:
  - removing all <!---->, <!...> and <?...?> from XML-RPC (unwanted comments)
  - removing whitespace inside <methodname> </methodname>


---------------------------------------------------------
* RTC SDK 2.0 beta - RC 10
---------------------------------------------------------

***Fix***

1) XML-RPC will now allow empty records using <struct></struct>


---------------------------------------------------------
* RTC SDK 2.0 beta - RC 9
---------------------------------------------------------

***Fix***

1) XML-RPC will now correctly handle Tags with inserted space between / and tag name, like < / double>


---------------------------------------------------------
* RTC SDK 2.0 beta - RC 8
---------------------------------------------------------

***Update***

1) I went through a few hundred "XML-RPC" related websites yesterday, testing how the XML-RPC
   parser (which is now part of the RTC SDK) will handle the data received from various implementations
   calling themselves "XML-RPC". I can't believe how much freedom some people allow themselves when
   it comes to "stretching" a standard to their likings. Since I want RTC SDK to be capable of handling
   even things which are only remotely similar to XML-RPC, I've done a number of additions to the parser
   to make it more tolerant to 3rd-party creativity. 

Here are a few things which RTC SDK will now be able to handle (correctly parse), none of 
which are part of the XML-RPC standard, but simply alternatives invented by "creative minds":

- Date/Time format "yyyy-mm-ddThh:mm.ss+timezone" ( standard is only "yyyymmddThh:mm.ss" )
- Escape characters &gt; &quot; &apos; &nbsp; &#xx; ( standard is only &lt; &amp; ),
  The use of plain "&" (should always be &apos; - which is required by the standard)
  Any other unsupported escape characters will be left unhandled (not raise an exception)
- Allowing comments in format "<!-- .... -->" (will be skipped as this is not part of the XML-RPC standard)
- Tags with inserted spaces like <double >, </ double>, < / double > (XML-RPC standard is strict and doesn't allow that)
- Inserted space in non-string value fields, like <i4> 12 </i4> (inserting whitespace inside a value is acrually not allowed in XML-RPC standard)
- Multiple values inside <methodresponse>, even without <params> and <param> (will be stored as an array, if more values are sent)
- Using the <fault> tag to enclose FaultCode and FaultString (should be in <struct>)