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.
No, that's it. 'variable[ _GET ][ "value" ]'
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.
Okay, I hope we will be able to nail them down.
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?
Yes, it would be the perfect choice.
[ I was talking about socket code only. ]
HB_INET*() is indeed strange :/
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 have no problem with that name.
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 :)
:) BTW, could you upload your filled items.dbf to the SVN?
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
