On Thu, 24 Jan 2008, Alexander S.Kresin wrote: > >So you introduced very serious limitations for your own code. > >Harder portability and you you will not be able to use other type > >of connections when we will add them. HB_SOCKET_STRUCT should hide > >platform and protocol differences. > I don't see limitations here. Server part is written mostly on > Harbour, at least those parts, which works with sockets - at Harbour > level there is no differense, what kind of data the socket is, the only > operation with it is pass it to appropriate socket function ( from > hbinet.c or any other ).
OK, at .prg level it will work. > The C level socket API is used in client part, because the RDD is > written on C. I don't see serious problem here, too, because I'm sure > that in the case of necessity appropriate separated parts can be easily > adopted. So how it will work with compressed socket when we add native support for stream compression? Using OS handles you are dropping all such extensions. For me it's very serious limitation. And what if Harbour socket will not have usable OS handle at all on some platforms? What if it will be necessary to hide some OS dependent differences? F.e. select() works a little bit different in MS-Windows then in *nixes. Even between *nixes there are some important differences in this function. Do you know these differences? Can you write a code which will work well with both versions? And what about other platforms? To resolve some problems it will be necessary to keep additional information inside socket structure so functions which will receive only OS handle without additional information cannot make well their job on all platforms. > >Can you give me any reason why you are not using PHB_ITEM pointers > >but low level OS handles directly? > The main reason was that I cannot place my additional socket functions > not in hbinet.c, but in my source files without making > hb_inetSocketFinalize() public - I suppose that if it is static, there > are reasons for it. Can you tell me what functionality is necessary for you? If it will be portable then we will add it to hbinet.c. There is absolutely no reason to make hb_inetSocketFinalize public until we want to keep sockets internals 3-rd party code independent and easy expandable. > The second is that I don't understand why hb_parptrGC(), > hb_inetSocketFinalize() are used instead of usual hb_parptr() and how to > work with them, I found it more easy for me to rewrite appropiate parts > of code than dig in it :). The answer is very simple. .prg code should protect against low level errors like GPF. hb_parptrGC() validate if given pointer is a pointer to valid socket structure. hb_parptr() will also work but it will accept all possible pointer items not only these one which point to socket structure. Look at HWGUI. There is no validation at all so user can pass wrong pointers or handles to functions which will accept them and later GPF. Such code is unsafe. We should always try to write code as safe as possible. > >I saw this thread and I thought that Mindaugas perfectly explain that > >it's not necessary to touch socket internals at all and there is no > >problem with hb_inetSocketFinalize() at all. You only need C level API > >to access Harbour sockets and of course we should add it. It will be > >very small modification so I can give it even today if it helps you. > It's very appreciated. And with hb_inetSocketFinalize() public :). As I said it's not necessary at all and so far you haven't answer why you need it. Again, please tell me which additional functionality is necessary for you and I'll add them to hbinet.c. If me make hb_inetSocketFinalize() public then we will open doors to create pseudo socket structures by 3-rd party code which will be accepted by our code with unpedictible results. F.e. someone could copy HB_SOCKET_STRUCT to his code and create new socket. Exactly like in RTL code. And it can be source of unpredictable errors because his code will have to be compiled with exactly the same alignment switches as core code. F.e. now hbole code borrowed from xHarbour needs 8 bytes alignment for OLE structures and because it access core HVM structures then also forces that HVM has to be compiled with 8 bytes alignment what increase memory consumption and reduce the HVM speed. For me it's very serious limitation and hbole code has to be fixed. > >> I've wrote basic part already, and few my applications works > perfectly > >>with it ( including such a big as Personnel and Salary accounting ). > >Again, It's very nice news. And if you can updated your code to use > >PHB_ITEM pointers as connection handles then I'll add Harbour public > >socket API ASAP. > Almost nothing should be updated there. Just a type of socket variable > in the workarea structure and calls of it in a couple of functions. Fantastic. I will work on basic version today. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
