Hi,
Probably a local variable container array could solve that,
so only one quasi-object needs to be passed around.
Variables are post, get, session, server, etc. I do not think I like to
use a single on variable and write: variable["get"]["value"] or
variable[2]["value"]. Or I've misunderstood your idea.
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.
I guess some differences in Windows vs. Linux socket implementation
still should be solved in my socket code. So, it is not perfect also. I
do not keep it in my head now, but I remember Przemek has mentioned on
the list some time ago.
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?
Here I'm not sure, if you talk about my socket code, or my uhttpd code.
If you talk about socket, so I do not like the name HB_INET*(), why
INET, why not IntraNet, or NovellNet (if I use IPX, SPX)? I like
"socket" name here, because the whole idea is to be as close as possible
to original socket implementation. So, HB_SOCKET*() could be a choice?
If you talk about uhttpd, I like this name, and I'm going to use for my
version of uhttpd. But I do not know how my uhttpd will be similar to
SVN's. Many alternative names can be used in Harbour SVN. If it is
example only, it could be just httpsrv. If it will turn into some
library it could be ex. Harbour Web Application Framework (hbwaf), or
any other.
I left uhttpd demo server running for weekend. It was working OK
for 24 hours until 13/Jun/2009 18:37:04 (the time of last query).
It seems, that all 50 thread (maximum number of threads) are blocked
in some operation like port read. I do not know the exact bug yet.
The problem was in HB_MUTEXWAITERSCOUNT(). I've just deleted my version
of function and used the new one from current SVN. Problem disappeared.
http://www.dbtopas.lt:8001/ provides Amazon like book service again :)
Regards,
Mindaugas
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
