On Thu, 23 Jul 2009, Miguel Angel Marchuet wrote: Hi,
> 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 ? I do not want to discard your work but such modifications as in xHarbour are technical nonsense. You copy code of existing DBF* RDDs and then you change their names adding 'RE' prefix and replace hb_file*() calls with hb_fileNet*(). It's exactly the same situation as with BMDBFCDX RDD which is copy of DBFCDX RDD with few small modifications when the same effect can be reached by implementing bit map functionality in new RDD which inherits from DBFCDX or any other DBF??X RDD, i.e. DBFNTX or DBFNSX. In such way work from beginning RMDBF??X RDDs. Looking at xHarbour source code I can see that you created yest another copy of dbfcdx1.c in source/rdd/dbfmdx/dbfmdx1.c which is not MDX RDD but simple copy of DBFCDX where you changed DBFCDX to DBFMDX and replaced original authors copyrights with your own. Copyright 2009 Miguel Angel Marchuet <miguelan...@marchuet.net> Over 90% of code in this file and in dbfcdx1.c so also in this copy is written by me. Rest by few others people but I do not see original authors copyright notes in source/rdd/dbfmdx/dbfmdx1.c. 1-st it's illegal so I hope it will be corrected soon or deleted from xHarbour CVS. It's my official request and I'm setting CC to xHarbour-devel. 2-nd it do not understand why you made such copy of DBFCDX and call it DBFMDX. It's still DBFCDX only so it confuses users and developers have to update both files so it's only additional problem/work for them. Now in xHarbour not only DBFCDX code exists in separate copy but all native RDDs are copied (also copy of copy like dmdbfcdx1.c) and in the copy only above cosmetic modifications (RDD name and hb_file*()-> hb_fileNet*()) are done. And all these modifications are not necessary at all. See note about virtual file handles in my previous message below. The same effect can be reached without changing even single byte in RDD code. It's enough to intorduce virtual handles to [x]Harbour FS API or at least hack single file source/rtl/filebuf.c and add such functionality only here and only for one hardcoded file name prefix, i.e. "netdb:". There is no reason to dulicate existing code. You only have to implement it cleanly. Current filenet.c is not MT safe at all. It has some MT locks copied from my original code in source/rtl/filebuf.c but they were designed for different context and they do not make MT safe code copied from leto DB which uses static variables (BTW in this file I also see only your own copyright note). source/rtl/hbip.c is not MT safe too and like filenet.c inherited from Leto static variables. Additional code in filenet.c inherited from Leto the comunication protocol which uses printf()/scanf() what forces using CRTL which may not be MT safe in some compilers and it's rather slow form of encoding/decoding messages. In summary if you can implement it in non invasive way as local solution without touching RDD code and the implementation will be efficient and MT safe then we can think about adding such code to Harbour but I would like to see final working code with working and free available server part before. Otherwise is only waste of your and other developers time. Sooner or later Harbour will have such functionality with virtual handles so anyone can write more or less efficient transport protocol and register it in HVM with some unique prefix i.e. 'netbd:'. It can be implemented also as 3-rd party closed source library (both client and server part). BTW seeing the client code I have serious doubts about current server code and it's hard for me to believe that it does not contain any existing Harbour or Leto code but of course I can be wrong and I do not want to waste my time to check it. best regards, Przemek > 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 _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
