Re: [twsocket] About HTTP client V6 changes to support .NET
> As to the support, email lists are much preferred here, as they just > work, so you don't have to go downloading the latest "news" etc, or > crawling a web-forum. I would just ignore a web forum, totally hopeless. But I would prefer an NNTP news server, it would need to be authenticated to allow private topics such as ICS-SSL, but would allow more separation of messages into useful topics with proper threading, such as announcements, beginners, ICS developers, etc. But I'd mainly prefer NNTP because I would not then be able to post private emails with ICS mailing list headers to the mailing lists, which I'm afraid I seem to have done at least twice recently. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] About HTTP client V6 changes to support .NET
> -Original Message- > From: Arno Garrels > 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. At least it'll be well documented, unlike much of the Indy changes the last year or so, especially the changes from V9.x.x to V10.x.x I sweated blood to fix some of my code, only to have it break again as a result of an update to the component/tool library. Sadly I made the mistake of buying the "In Depth book". It's not very deep, if you get my drift. As to the support, email lists are much preferred here, as they just work, so you don't have to go downloading the latest "news" etc, or crawling a web-forum. Plus, for all the other stuff that comes along, I quite often learn something that'll be useful to me later, or provokes me to go and change something I've done in the past, that in turn shows up and allows me to fix a problem I didn't know I had! Not only that, everyone here is just so polite! This ICS list, is also a lot more useful and enlightening in general, than any of the (fragmented) Indy lists. My personal sixpence worth. Keep up the good work one and all... Still "playing" with ICS, not done anything wonderful with it yet... One day, just using it as a learning tool these days. As to .NET being "inefficient" at building strings... Hm... Wonder where all the "bright young things" learn their trade these days. Sadly all too common in many walks of life, especially in engineering. Tried proven and trusted techniques, are just forgotten as they are not taught any more because they are "old". So the new flock re-invent the wheel again, just that they don't quite get it round or balanced this time, plus it's not fully tested before letting the users loose with it. Someone then comes up with the obvious fix, and they praise it as a wonderful "advance" in technology I'll go hide in my hole again Got a call to make anyway... Cheers.. Dave -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] About HTTP client V6 changes to support .NET
> Small OT question: which FastMove do you use? John O'Harrow's v3.03 Dec 2005. It's 1600 lines of code, against the 14 lines for the 'pure pascal' version, but is very efficient. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] About HTTP client V6 changes to support .NET
Scrive Angus Robertson - Magenta Systems Ltd <[EMAIL PROTECTED]>: [...] > And if the Move function is used to move data around, specifically when > the project uses the FastMove unit which has very efficient move code. Small OT question: which FastMove do you use? Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] About HTTP client V6 changes to support .NET
>> Using a dynamic array of byte will not slow down the component if >> the array size is not constanly changed. > > And if the Move function is used to move data around, specifically when > the project uses the FastMove unit which has very efficient move code. That's not a problem. The code can be conditionaly compiled to use move or fastmove. The problem is to have a class interface which is the same on both platforms so that an application code can be the same. > Mind Move uses pointers, so might be useless in .net, but that's a > problem for people wanting to use .net, not win32. Indeed. Because .NET doesn't accept pointer, the code is frequently slower. But again, this is not important and do not compromize win32 code. I restate it: the code inside the class can be changed using conditional compile, but not the class interface, specially the event handlers signature which mess all the forms. I'm trying to have the best portable code to easily maintain a single set of components and samples. Take ICS for Kylix: the code has not been updated with all the changes in win32 code because it is different code. It is simply too time consuming to maintain both sets of source code. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] About HTTP client V6 changes to support .NET
Angus Robertson - Magenta Systems Ltd wrote: > Mind Move uses pointers, so might be useless in .net, but that's a > problem for people wanting to use .net, not win32. If so, I'm happy again. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] About HTTP client V6 changes to support .NET
> Using a dynamic array of byte will not slow down the component if > the array size is not constanly changed. And if the Move function is used to move data around, specifically when the project uses the FastMove unit which has very efficient move code. Mind Move uses pointers, so might be useless in .net, but that's a problem for people wanting to use .net, not win32. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] About HTTP client V6 changes to support .NET
>> 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 [0..2047] 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 1 do
B1 := DA[I];
t2 := GetTickCount;
for J := 0 to 1 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.
--
Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] About HTTP client V6 changes to support .NET
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] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] About HTTP client V6 changes to support .NET
Scrive Francois PIETTE <[EMAIL PROTECTED]>: [...] 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 OS. Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] About HTTP client V6 changes to support .NET
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 -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] About HTTP client V6 changes to support .NET
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] http://www.overbyte.be/eng/overbyte/teamics.html 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: OnDocData 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 OnDocData to make it > compatible with .NET without breaking existing code. Of 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 OnDocData 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 OnDocData as it is for win32, > suppress it for .NET and create a new event for both platforms. Old > 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 OnDocData 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 ? > > -- > Contribute to the SSL Effort. Visit > http://www.overbyte.be/eng/ssl.html -- > [EMAIL PROTECTED] > http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] About HTTP client V6 changes to support .NET
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: OnDocData 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 OnDocData to make it compatible with .NET without breaking existing code. Of 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 OnDocData 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 OnDocData as it is for win32, suppress it for .NET and create a new event for both platforms. Old 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 OnDocData 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 ? -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
