On Thu, 18 Jun 2009, Szak�ts Viktor wrote: Hi,
> Is there any objections in adding new socket API > developed by Mindaugas to core RTL lib? > To me it seems a better / cleaner implementation, > with a more natural Harbour level API. It's also > friendlier with MT. Just like hb_inet it's not MT safe on all platforms. It also does not touch important places which needs special solutions for MT safe portable code so it's not friendlier with MT. > Current hb_inet*() API has some other problems, > and it was planned to be replaced. Yes it is, but to make it well we need to give full functional replacement. Current socket library covers ~20% of hb_inet*() functionality. > So, the idea here is that I add now socket.c to > core, we will fill the missing gaps, at the same > time users can start to get familiar with it and > if everything is okay with it, we promote it as > the primary "inet" API of Harbour. In the future > or at the same time we retire the old API with a > future HB_LEGACY_LEVEL (and/or move it to a separate > contrib, or xhb lib or an example lib). I think it's bad idea. We will have two socket implementation and none of them will be the final one so no one can start to to update his code and migrate to suggested solution because it still won't exist. The second bad thing caused by such raw wrappers is moving the problem with platform differences to .prg level. Now hb_inte*() function hides some of them so it's possible to create portable .prg code. With new socket code platform differences have to be resolved at .prg level using some #ifdef __PLATFORM__* conditional compilation. Most of users do not know these differences so they will have problem with portability. Current socket library is only wrapper to few socket functions without many important things. For C programmers who knows well BSD socket functions is easier to use it then hb_inet*() functions but unfortunately it may also close the possibilities to hide platform differences by some intermediate layer. In current state it also cannot be used as hb_inet replacement because it supports only small subset of existing functionality. To make something really constructive we should rather create full hb_inet* replacement with C API not just few function wrappers. Otherwise we will only irritate Harbour users by introducing temporary solutions to core code. Usually people do not have time for never ending code updating. I do not like current hb_inet* implementation but its successor should cover most of current functionality and resolve existing problems. Experimenting on core code without clear goal for final solution is the worst thing we can do. We do not create stable and final API and sooner or later we will break something. Practice shows that using sockets in C code is not easy for many programmers and also core developers, i.e. over year ago Miguel broke inet.c code in xHarbour and so far no one can fix it though I've seen few bug reports on xHarbour news with self contain examples. They were for MT mode but problem exists also in ST builds in all xHarbour builds created in last year. Current hb_inet* code is far from being good and complete solution but as least is working in known way and I would like to keep it until we will not have fully functional replacement. best regards, Przemek _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
