On Wed, 23 Jan 2008, Alexander S.Kresin wrote: > I'd prefer to not duplicate hbinet.c and make all necessary > modifications there, too. But I don't sure that all my changes will be > suitable for others. > I've made already all what I need now. > First of all - C level API. Appropriate functions are rewritten, so > the Harbour level functions ( HB_FUNC(...) ) are wrappers over those C > level functions. This is made, though, only for the basic functions, > which I need - connect, accept, send, receive, select.
Fine, we also have to add it. > Secondly, I've added functions to select from multiply sockets. Yes, it's strongly needed function. Privately I was using my own wrapper to select(). > And, finally, and this is what, probably, will not be suitable for > others - I got rid of the HB_SOCKET_STRUCT and appropriate stuff, so the > sockets are directly passed as parameters and returned, assuming that > included in HB_SOCKET_STRUCT things may be moved to Harbour level, if > needed in specific application. 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. Can you give me any reason why you are not using PHB_ITEM pointers but low level OS handles directly? > I did this to make the code less complicated, to simplify writing > additional functions - now, due to the hb_inetSocketFinalize() and all > related gc things I can't place new functions in other file ( see the > hbinet.c thread ). 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. > The project I'm working on is a db server with appropriate rdd as a > substitution for ADS. ADS is a perfect product, but it isn't free and it > is quite expensive. Besides, writing such a server specially for > Harbour will help to avoid some problems, which ADS has ( now to solve > them we need to invent different workarounds ). And, finally, we can > implement some new interesting stuff - as server-side harbour level > procedures, for example. Very good idea. I started to work some time ago on NETRDD but I've never found time to finish it. Anyhow such project is perfect example why you should not use directly OS connection handles. In fact you do not need TCP/IP connection but any transport layer. F.e. in *nixes working locally it will be much more efficient to use unix sockets instead of TCP ones - they are much faster. If you will use PHB_ITEM as socket handler then all protocol differences will be hidden by HBINET code. > 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. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
