I didn't inspect the code yet, but it would be nice
to be able to pass LOCAL vars (f.e. array/hash container
of values) down the path. To make it possible to avoid
memvars.
It is possible to pass all them as locals, but I've tried to avoid
passing of 4 or 5 parameters though a few function in the stack.
Probably a local variable container array could solve that,
so only one quasi-object needs to be passed around.
Next question: Why don't we apply these to our core? It's a waste
of resources to have two socket APIs.
I do not want to be the one who tries to push his own code into SVN.
If many people find it useful, I has no objection to put it to SVN.
But I do not care about current HB_INET* code, I do not want to
answer question "how to move from old socket function to new?",
"does backward compatibility layer exists?", etc., because I never
used the old socket code. We have currently similar situation in OLE
world. I stopped use CVS OLE code, and I wrote my clean code, after
I was unable to manage hacky side effects of public CVS
implementation. But I use OLE only to import export code from EXCEL,
no GTWVG, no ActiveX, I'm not able to answer FiveWin user howto move
their code to new OLE implementation. I do not want to be in same
situation in socket library also.
Well, if not in this major release, but we can
implement a (your) superior socket implementation.
I don't know what exactly is the problem with current
one, only that it's less MT friendly, plus I saw some
level of clumsiness when looking into the source,
and saw some intent from Przemek for a rewrite.
These means to me that the current core API isn't
perfect, not up to Harbour quality.
Probably we should eventually move out current
implementation to xhb lib as is (or move it to a
separate compatibility lib), and move yours
to the core with function name + other tweaks if
needed to make it about feature par with current
one.
This would also mean to change all our hb_inet*()
dependent code to use the new API (like hbtip).
So some sort of upgrade path needs to be defined.
Some help from your side would certainly be
appreciated.
I'd be happy to see your code in SVN, and if you
don't mind I can even upload it.
All we need to find is a name, because we already
have uhttpd, we can rename existing one, or rename
your new one, but which and to what name?
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
