updates.txt

Delphi快速开发Web Server

- Using the <methodfault> tag instead of <methodresponse> to enclode fault data
- Sending records using <member></member> without a <struct> parent
- Sending named record fields using <name></name><value></value> lists without <struct><member> parents
- accepting function calls using <call> instead of <methodcall>
- accepting Date/Time values Using <datetime> or <timestamp> instead of <datetime.iso8601>
- accepting Binary Streams using <base64binary> or <binary> instead of <base64>
- accepting NIL values using <string/>, <double/> or any other type name (this is different from sending an empty or default value using <string></string> or <double></double>, since data type will be rtc_Null)
- accepting valued enlosed in multiple <value>...</value> and/or <data>..</data> tags (why someone does this, is beyond my understanding)
- accepting F, N, FALSE and NO als alternative values for a boolean "False" (should be '0')
- allowing <params/> in <methodcall> when there are no parameters (should be <params></params>)
- allowing parameters in <methodcall> to be sent without enclosing them inside <params> and/or <param>
- Allowing arrays to be sent without enclosing them inside <data> (<array><data><value> is defined by the XML-RPC standatd)
- allowing arrays and records to be sent using the <params> tag instead of <array> or <struct>

In other words, RTC SDK will now be able to parse the wildest XML-RPC variations, like ...

<call><methodname>hola</methodname>
  <name>test</name>
    <params><i4>12</i4><string></string><double>1.4</double></params>
  <name>hola2</name>
    <double>1.3</double>
</call>

... which should actually look like this (below) if it was real XML-RPC ...

<?xml version="1.0"?>
<methodCall><methodName>hola</methodName><params>
<param><value><struct>
<member><name>TEST</name><value><array><data>
<value><i4>12</i4></value>
<value></value>
<value><double>1.4</double></value>
</data></array></value></member>
<member><name>HOLA2</name><value><double>1.3</double></value></member>
</struct></value></param>
</params></methodCall>

As long as it looks like XML-RPC, it should be OK. Naturaly, RTC will not "swallow" errors in XML. 
If there is a grave error in the string (like missing closing tag, misplaced tag or invalid tag), 
there will be an exception raised. If it's on the Server-side trying to prepare a remote function call,
client will receive the excepion with the appropriate error message.

PS. XML-RPC data generated by the RTC SDK will always be 100% XML-RPC compliant, 
    strictly following the XML-RPC standard definitions, so you don't have to worry about
    other implementations won't be able to decipher the data you send out using a 
    RTC Client or Server (as long as they are capable of parsing XML-RPC).

***New***

1) "Delphi_XMLRPCTest" project in "QuickStart"
   You can use this to test how RTC will be parsing XML-RPC data.
   Simply enter some XML-RPC string and click on the button to have RTC parse the data
   and generate a new XML-RPC and RTC string with the same content.


---------------------------------------------------------
* RTC SDK 2.0 beta - RC 7
---------------------------------------------------------

***Fix***

1) Fixed a Security Exploit in the rtcFileProvider implementation, which 
   could have been used to download files outside of the Web folder.


---------------------------------------------------------
* RTC SDK 2.0 beta - RC 6
---------------------------------------------------------

***Opera work-around***

1) Opera Browser has a bug which causes endless waiting times when it receives 
   a response with content-length 0. To avoid this problem with the Opera browser,
   I've modified the rtcFileProvider to return a short error message as content body,
   to avoid Opera from waiting indefinitely for something it won't ever receive.


---------------------------------------------------------
* RTC SDK 2.0 beta - RC 5
---------------------------------------------------------

***Update***

1) All appearances of ...
       try x:=IntToStr(s); except x:=0; end; 
   changed to ...
       x:=IntToStrDef(s,0);

---------------------------------------------------------
* RTC SDK 2.0 beta - RC 4
---------------------------------------------------------

***New stuff***

1) Activated XML-RPC support for the RTC Messenger Server

2) Added "useProxy" and "use XML-RPC" options to the RTC Messenger Client 
   and tested all combinations with the new RTC Messenger Server - it works!

---------------------------------------------------------
* RTC SDK 2.0 beta, RC 3
---------------------------------------------------------

***Fixes***

1) RTC SDK compiled in Delphi 4 and 5 will now auto-convert field names to UpperCase, even if received in mixed case,
   so that new Clients and Servers compiled with Delphi 4/5 will work with clients and Servers writen with Delphi 6 and later, 
   even if those Clients and Servers are using mixed-case field names.

2) For compatibility reasons with older RTC Clients and Servers, which might not be converting all Field names to uppercase 
   if received in mixed-case, default option is now to use the same automatic uppercase conversion with RTC SDK 2.0 as in older 
   RTC SDK versions. To use mixed-case field names, define the "RtcMixedCase" compiler directive in the "rtcDefs.inc" file.

   This compiler directive will be required if you should need to communicate with external providers using XML-RPC which use
   case-sensitive field names in their XML-RPC calls, so you will need to send field names in a specific up/low-case format.

   In my opinion, XML-RPC implementations should be case-insensitive, but ... you never know what you could bump into.
   Since it is nothing specificaly defined whether field names are to be treated case-sensitive in XML-RPC, some XML-RPC
   implementations might not be "as cautious" as RTC SDK and require you to send data using specific mixed-case strings.


---------------------------------------------------------
* RTC SDK 2.0 beta, RC 2
---------------------------------------------------------

***Fixes***

1) RTC SDK 2.0 now compiles under Delphi 4 and 5, also.

   "TStringList.CaseSensitive" property was added in Delphi 6, so Delphi 4 and 5 weren't able to compile the new changes for supporting case-sensitive field names in RTC structures.
   This update will not use the old implementation (converting all field names to uppercase) when compiled with Delphi 4 or 5, 
   while the same code compiled with Delphi 6 and up will use the new CaseSensitive property to allow sending parameters using mixed case (not only uppercase).


---------------------------------------------------------
* RTC SDK 2.0 beta, RC 1
---------------------------------------------------------

***New stuff***

1) rtcFileProvider now supports resuming downloads by implementing the "Range" HTTP header

2) rtcISAPIServer has a new property "ForceSingleThread", which can be used to force all calls to your code to be single-threaded (requests will be processed one-after-another)

3) RTC remote functions now support a new format: XML-RPC, which you can use to write remote functions with RTC and make then accessible to external providers, and/or call remote functions provided to you by external providers.

4) Added a new demo called "WebStress_Client", which you can use to stress-test any Web Server.

***Fixes***

1) File upload and download now works correctly with ISAPI extensions under MS IIS

2) "varOleStr" will now correctly be mapped to "WideString" when using the "Value" property to assign Variant values to RTC objects

3) Min Thread Pool size changed from 20 to 3, so your apps will close faster when run under Delphi.

4) Fixed a client-side issue handling the "100 Continue" response from a Server (when useProxy=False).

5) Parameter names in TRtcFunctionInfo, TRtcRecord and TRtcDataSet are no longer automaticaly stored as uppercase, to allow creating case-sensitive XML-RPC requests. "Searching" the values is still case-insensitive, so your existing code should remain compatible.

6) All Help files have been updated to the latest source code version

---------------------------------------------------------
* RTC SDK 1.9 l
---------------------------------------------------------

This is a WinSock performance update, which applies to Stand-alone RTC Servers and stand-alone RTC Clients with UseProxy=False. There are 3 major internal changes:

1) Using larger internal sending buffers to reduce the number of WinSock API calls

2) Allowing up to 20 internal loops when buffers are ready to accept new data directly after the WinSock API call (instead of posting a message). This reduces the time-delay between packages being sent

3) Packing HTTP headers into a buffer when we are expecting more content to be sent in the request/response instead of directly sending the headers out. This results in the headers being sent out with the first content body package, using a single WinSock API call, reducing the number of WinSock API calls and the number of TCP/IP packages sent for smaller requests/responses. 

For example, it will now only require 1 TCP/IP package to be sent for requests with less than 1460 bytes of data. Before this update, there were always at least 2 TCP/IP packages sent for requests and responses with content body (1 for the headers and 1 for content body).

All applications which start sending content body from the OnDataReceived event will work as usual and all following events will be triggered as expected.

But, in case you had only used WriteHeader from the OnDataReceived event and waited for the OnDataSent event to trigger so you can start sending content body, you should change that implementation to start sending content body from the onDataReceived event. This applies only if there is content body to be sent. When sending a request or a response without content body, there are no changes in behavior.

---------------------------------------------------------
* RTC SDK 1.9k - beta3
---------------------------------------------------------

There shouldn't be any problems using this new RTC SDK version, but I've decided to make this update as a separate download with a "beta" sufix because I am going on a vacation tomorrow and won't be back for 3 weeks. I think it would be fatal if we only had one version and it was "untested" (has some major changes which could affect some applications behavior).

I made a number of tests with this new update and it looks as though all the "old" functionality is still working like it did before, but I still can't guarantee that some of the changes won't "break" some existing applications, because some of the components behavior will change when of a communication problem with the Server "happens".

Here is what has changes in this update:

1) I've made some modifications to assure that, in case there were errors while sending requests to the server (while calling remote functions or requesting/sending files), the "OnResponseAborted" event on TRtcHttpClient and TRtcClientModule components will get triggered for each request generated by you and ... "ResultAborted" event on TRtcREsult will be triggered for each remote call (using the "Call" method). 

In other words, you can now safely use the ResultAborted event on your TRtcResult components to react to situations when a specific remote function call wasn't executed on the Server and/or you didn't receive a valid response, in which case the OnResult event won't be fired for this call.

There will be exactly one call to the OnResult event for each call that "goes through" or one call to "ResultAborted" for each call that "doesn't go through". By setting a reasonable value for TRtcClientModule's the AutoRepost property (not more than 2) and not using the "SkipRequests" method to clear the request buffer, you can rest assured that each one of your Call's will either fire the OnResult or the ResultAborted event on the TRtcResult component.

2) "CancelRequests" method was added for TRtcDataClient and TRtcClientModule components, which will automaticaly be called by the connection component if a request "didn't go through" and wasn't planned for re-posted (none of the OnResponseAborted events called "Request.Repost"). If more than one request was in the request queue at that point, OnResponseAborted and ResultAborted events will be triggered for each of them before the request queue is cleared.

The behavior of the "SkipRequests" method didn't change, to keep the new components backwards-compatible with code used in "old" clients, where all requests were usually skipped from the first OnResponseAborted event. This means that you can continue using the old approach to clean-up the request queue by callind SkipRequests, which will avoid calling OnResponseAborted events for pending requests which will be cleared from the queue. But, if you use SkipRequests, you have to know that OnResponseAborted and ResultAborted events won't be fired for requests which weren't sent out yet.

3) When using the WinSock API (useProxy=False, non-blocking mode), "RequestAborted" events will be fired the same way they are being fired when the WinInet API is in use, which means that using a different setting for UseProxy property shouldn't make a notable difference in application behavior from this version on. 

Since WinSock works differently than WinInet, to achieve the appearance of similar behavior, OnRequestAborted events will now be fired if a connection couldn't be established (OnConnectFail and OnConnectError), which actually happens before we even tried to send the request. In other words, a failed connect attempt will now be counted as a failed request attempt, which is identical to the behavior implemented using the WinInet (UseProxy=True, blocking mode).

4) Since requests will now have to be reposted when connection attempts fail or if there was an error connecting (for example, DNS couldn't be resolved), a new event "OnRepostCheck" is now added, which will be fired after the OnConnectLost, OnConnectFail and OnConnectError events, so you can check the request which is about to be posted and call "Request.Repost" to repost the request, or use the AutoRepost property and let the component handle reposting automaticaly. This new "OnRepostCheck" event will always be fired before the "OnResponseAbort" event, if there was a request waiting to be sent to the Server, but wasn't reposted automaticaly by the component (see AutoRepost property).

With all the changes in this update, you can set your connection component's "ReconnectOn" properties (ConnectLost, connectFail, ConnectError) to TRUE, define a value for your rtcClientModule/rtcDataRequest's AutoRepost property, set up events to be fired if a request was successful (as usual) and use "OnRepostCheck", "OnResponseAbort" or "ResultAborted" events (either one will do) to react on problems in communication.

---------------------------------------------------------
* NexusDB transport plugins for the RTC SDK
---------------------------------------------------------

Plug-ins for using the NexusDB components as a transport is 
now included in the RTC SDK package ("LibPlugins" folder).

You will need NexusDB components to compile the plug-ins.

Check your NexusDB package for a more recent version of the plug-in,
or contact NexusDB support if you are missing the RTC plug-in.

--------------------------------------------------------
* Support for Message-based Third-party transports
---------------------------------------------------------

NEW: TRtcMessageClient and TRtcMessageServer components

You can use third-party Message-Based transports like NexusDB to tunnel all RTC communication, 
which makes it easy to integrate a RTC Server as a plug-in for a NexusDB Server and use 
RTC Client components to access the RTC Server through NexusDB connections.

By using the new message-based communication components, you can also directly link RTC Client 
and RTC Server components in one application, without the use of any other transport (like TCP/IP).

---------------------------------------------------------
* ISAPI optimization
---------------------------------------------------------

rtcISAPIServer component is now using a Connection components pool, so that connection 
components don't have to be created and destroyed for each request being processed.