Hi Miguel,
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 ?
As I wrote a few e-mails ago, I don't agree to upload this
either to contrib, and for sure not to core. It duplicates
_a lot_ of code (duplicate RDD code, duplicate file access
code), adds non-compliant function names, adds a duplicate
IP stack API.
And what it offers doesn't add any robustness, or extra
remote capability to dbf access, it just replaces known OS-level
FS network protocols with a proprietary one.
Since Harbour is an OSS project with certain licensing
requirements, any closed source parts automatically means
exclusion from repository.
BTW, a lot of existing code has been re-copyrighted, which
is wrong (= not legal). When starting with copying existing
code, the new contributor is expected to leave original copyright
message intact and add his own as an additional one.
So, overall, my opinion is a strong no for inclusion of this
feature to Harbour repository.
Brgds,
Viktor
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
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
