Hi Przemyslaw virtual file handles will help library like BMDBFCDX,NETRDD to not have duplicate code Can you made a template of this conversion will BMDBFCDX be sample for this conversion? After your guideline Miguel can add his netrdd in harbour? I propose write "guideline.txt" searching Przemyslaw's post in harbour
Miguel works seem have advantage of speed in runtime and this for windows can be useful 2009/7/23 Przemyslaw Czerpak <dru...@acn.waw.pl> > On Thu, 23 Jul 2009, Miguel Angel Marchuet wrote: > > 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 > -- Massimo Belgrano
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
