I'm working on V6 code to make it .NET compatible. Actually I'm working on
the HTTP client component. In that component, there is not much to change to
make it compatible with .NET. But there is one annoying change: DocData
event has a pointer argument and this is defenitely not compatible with
NET. The pointer is actually pointing somewhere into FReceiveBuffer.
I'm not sure how to change the component and the DocData to make it
compatible with .NET without breaking existing code. course I could
change the event signature for .NET only. So there would be no problem in
win32 and no problem in .NET. But the same application code could not be
ported from one platform to the other.
Another possibility is to completly change the DocData event signature so
that it is compatible with both win32 and .NET. This of course would break
all existing code.
A third possibility is to preserve DocData as it is for win32, suppress it
for .NET and create a new event for both platforms. code would continue
to work and yet new code could be written to be the same for both win32 and
NET. Conditional compilation could be introduced to remove the current
DocData to help make sure new code use only the new event.
I think about a new event of type TNotifyEvent (that is no argument except
sender). Actual document data could be retrieved either from component
runtime properties or copied using a new method (a kind of Receive).
Internally, the current implementation use a fixed array of char as receive
buffer (FReceiverBuffer). I think about changing it to a dynamic array of
bytes which is the best data type for .NET when you need to receive any
datatype. You can then transfer data to any variable of any data type. And
this code is also quite good in win32.
Any opinion ?

Hello Francois,

V6 is still in beta state, that's why I prefer the best solution
regardless whether it breaks existing application code or not, as
long as such 'breaking' changes are well documented.

Just my two cents.

Arno Garrels [TeamICS]

Francois PIETTE wrote:
I'm working on V6 code to make it .NET compatible. Actually I'm
working on the HTTP client component. In that component, there is not
much to change to make it compatible with .NET. But there is one
annoying change: DocData event has a pointer argument and this is
defenitely not compatible with .NET. The pointer is actually pointing
somewhere into FReceiveBuffer.

I'm not sure how to change the component and the DocData to make it
compatible with .NET without breaking existing code. course I could
change the event signature for .NET only. So there would be no
problem in win32 and no problem in .NET. But the same application
code could not be ported from one platform to the other.

Another possibility is to completly change the DocData event
signature so that it is compatible with both win32 and .NET. This of
course would break all existing code.

A third possibility is to preserve DocData as it is for win32,
suppress it for .NET and create a new event for both platforms.
code would continue to work and yet new code could be written to be
the same for both win32 and .NET. Conditional compilation could be
introduced to remove the current DocData to help make sure new code
use only the new event.

I think about a new event of type TNotifyEvent (that is no argument
except sender). Actual document data could be retrieved either from
component runtime properties or copied using a new method (a kind of
Receive).

Internally, the current implementation use a fixed array of char as
receive buffer (FReceiverBuffer). I think about changing it to a
dynamic array of bytes which is the best data type for .NET when you
need to receive any datatype. You can then transfer data to any
variable of any data type. And this code is also quite good in win32.

Any opinion ?

I am a newcomer to using ICS and have been very pleased with it so
far. I prefer the non-blocking functions to anything I have seen in
Indy, and I prefer the reduced number of components. I originally used
Argosoft Internet Mail Suite before converting to Indy a couple of
years ago.

As far as .NET goes, I have no desire to compile the same source for
multiple platforms. If ICS.NET is just similar to the Win32 library it
would work for me to have a starting point. I would be using it with
C# or Chrome, and certainly never VCL.NET. If VCL.NET is a requirement
for ICS.NET, then I'll have to look into using another library or API
when I create new .NET applications.

Sidenote: My only wish for ICS is that the support from you and peer
to peer was using regular newsgroups and not a mailing list. I just
like them better.
-Johnnie Norsworthy

Scrive Francois PIETTE <francois.piette (AT) overbyte (DOT) be>:

[]

Generic speaking, I think that the introducing of an incompability is
acceptable when:
- the application will not compile so the developer get the attention of the
problem
- the changes needed are documented
- these changes are few and quick to apply.

About which one is better I have no idea, but I'm with Arno's opinion. I
prefer the best solution for each platform. If the use of an array of byte
will slow down the Win32 version then keep the use of pointer for Win32 and
use the array in the .net version. This is important for components like ICS.

For a .net porting I don't think that a developer can expect to port the same
application to a different platform without any changes. It is different if
the developer want to keep it compatible with both platform, but I don't know
if this make sence since both "platforms" working on Windows S.

Bye, Maurizio.

This mail has been sent using Alpikom webmail system
http://www.alpikom.it

Maurizio Lotauro wrote:
I prefer the best solution for each platform. If the use of
an array of byte will slow down the Win32 version then keep the use
of pointer for Win32 and use the array in the .net version. This is
important for components like ICS.

I second that, I don't want to give up high speed of ICS Win32 just
to support .NET which I do not use (and will not use unless a customer
realy wants it). Any additional move of data in memory slows down
performance.

Arno Garrels [TeamICS]

>I prefer the best solution for each platform. If the use of
>an array of byte will slow down the Win32 version then keep the use
>of pointer for Win32 and use the array in the .net version. This is
>important for components like ICS.
>
I second that, I don't want to give up high speed of ICS Win32 just
to support .NET which I do not use (and will not use unless a customer
realy wants it). Any additional move of data in memory slows down
performance.

Using a dynamic array of byte will not slow down the component if the array
size is not constanly changed. Adressing an element in a fixed array or
dynamic array roughly takes the same time. It is even a little bit faster
(Tested with D7) to access the dynamic array !

procedure TestMe;
var
DA : array of byte;
SA : array [02047] of byte;
B1 : Byte;
B2 : Byte;
I : Integer;
J : Integer;
t1, t2, t3 : Cardinal;
begin
SetLength(DA, 2048);
I := 5;
t1 := GetTickCount;
for J := 0 to 100000000 do
B1 := DA[I];
t2 := GetTickCount;
for J := 0 to 100000000 do
B2 := SA[I];
t3 := GetTickCount;
writeln('Dynamic: ', t3 - t2, ' Static: ', t2 - t1);
readln;
end;

You can play with optimization and range checking to see the impact of those
options.