> > > 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. > > > > Current hb_inet*() API has some other problems, > > and it was planned to be replaced. > > As you know I'm heavily using hb_inet and hbtip. > What do you mean for "replaced"?
I've written it in the next paragraph. For sure we should deal with this fact, since the current API is very likely to be used by 3rd party code, so as I said, first we should get the new API up to speed, meaning it works equally well on all platforms and gives answers to all problems HB_INET*() could solve. We can start this process by adding the new HB_SOCKET*() API to the core. This phase doesn't touch HB_INET*() in any ways. Given there is enough mojo in the team this process can be finished in next major release after 2.0. Already in this phase we may add optional support for HB_SOCKET*() API to hbtip, enabled with a build switch, for testing. (just like we do now for httpsrv). If that phase is done, and we know the new API is a proper replacement and fully core quality, we can start the process to make it the primary API and start dephasing old HB_INET*() API. This can mean several things, we should switch from HB_INET*() usage to HB_SOCKET*() usage inside our repository (f.e. hbtip). At the same time we should announce it as legacy, let time for users to adapt their code. As a final stage HB_INET*() API can either be moved into xhb lib, or moved to a separate lib, or moved to examples as a legacy lib. Additionally we can rebuild HB_INET*() as a compatibility layer on top of HB_SOCKET*(). This way it's probably even safe to store it in core for a longer time. The exact path should depend on details not easily known in advance. Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
