I upload it as soon as possible, i don't forget harbour.
the work is not finished yet. but my intention is to convert
all dbf based rdds into remote, adding sessions and modifing
filebuff.c to work with remote server or not. the connection
will be saved optionally at session.
sorry for my english.
The server is not decided yet to be open or close. For this reason
we are waiting.
Any opinions ?
Best regards,
Miguel Angel Marchuet
Przemyslaw Czerpak escribió:
On Wed, 22 Jul 2009, Itamar Lins wrote:
Hi,
The harbor will have native support net rdd for the core team ?
Because LetoDB is god product for local LAN but is very slow, impracticable
with WAN via ADSL for exemple.
If you ask about sth like just committed to xHarbour RE* RDDs then I do not
think it should be part of core code though it someone wants to port it as
fully contrib extension then why not.
IMHO any remote RDD which can be part of core code should be fully
implemented as remote RDD, partial replacing only transport layer
is IMHO waste of time. For sure it gives some speed improvement with
minimal modifications to original code but the same effect can be reached
with existing API by introducing dedicated file handles. See in our
TODO file:
Assign to: <nobody>
Detail...: Add support for virtual file handles and registering some
meta handles so it will be possible to make:
h := fopen( "gzip:/tmp/myarchive.gz", FO_WRITE )
fwrite( h, cData )
fclose( h )
or:
h := fopen( "tcp:some.host:port", FO_WRITE )
...
or:
h := fopen( "|lpr -PLaserJet", FO_WRITE )
...
or:
h := fopen( "gunzip /tmp/myarchive.gz|", FO_READ )
...
etc.
Status...: Open.
I haven't check details of the recent xHarbour modifications but ChangeLog
and short look at .diff suggests that the same effect can be reached by
adding support for above virtual file handles and implementing dedicated
for Harbour trivial file server so using existing DBF* RDDs Harbour user
can simply make:
use netdb:some.host:port:file ...
instead of:
use file ...
and the effect will be exactly the same.
I do not see big sense in coping source code of existing DBF* RDDs with
different names and replacing in the copy all hb_file*() calls with
hb_fileNet*(). Such modifications in core code for me only introduce
duplicated source code so for active developers it means double work
when sth has to be fixed/modified/extended. As contrib extension it
can be at least ignored so in such version is acceptable for me just like
BM* RDDs. Anyhow if someone plans to port this modifications to Harbour
then I suggest to invest the time in different way and add support for
above virtual handles. At least in some limited way inside
source/rtl/filebuf.c. Probably it will need less modifications then
porting all recent xHarbour modifications and the result will be the
same without creating redundant code.
best regards,
Przemek
ps. I still plan to work on real remote RDDs for Harbour but I do not know
when I'll find time for it and I do not know if I release it as open
source project so if anyone plans to work on it too please do not count
on me in this job. Now I do not know what I'll do and I do not want to
block anyone else in his plan.
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
__________ Informaci�n de ESET NOD32 Antivirus, versi�n de la base de firmas de
virus 4268 (20090722) __________
ESET NOD32 Antivirus ha comprobado este mensaje.
http://www.eset.com
__________ Informaci�n de ESET NOD32 Antivirus, versi�n de la base de firmas de
virus 4268 (20090722) __________
ESET NOD32 Antivirus ha comprobado este mensaje.
http://www.eset.com
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
