Okay. On Thu, Jun 18, 2009 at 10:17 PM, Przemyslaw Czerpak <[email protected]>wrote:
> 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 >
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
