Przemek,
> No Ron. It isn't. It's not real NETRDD. It inherits all overhead
> caused by index file processing on client side.
This is actually an ADVANTAGE (distributed processing) - what advantage do
you see in loading Server with ALL processing, as the client seat & wait?
This also means that no limit exists on Index Expressions, no artificial
fields should be created, and that by TECHNICAL DEFINITION the RDD is 100%
compatible.
> It only replace
> transport layer so instead of OS file server local one is used
> but nothing more is changed.
Like all brilliant ideas, simplicity IS the key.
> Maybe it's faster in some networks
> due to reduced some static costs but for me it's really technical
> nonsense as part of RDD modifications not worth to invest time and
> I'm not alone in such opinion
If it is at least as fast (if not faster), and if it is 100% compatible *by
definition*, and if it is so simple (as you admit), then what exactly is so
bad? Surely you can't be serious that using sscanf() and sprintf(), or C RTL
in general, is a no no, or else ALL of [x]Harbour is a technical nonsense!
[Please don't try to blame it on MT safety, because surely you know how
simple it is to make it MT safe.]
So what exactly makes it a "really technical nonsense" ?
> though as yet another virtual file
> type which does not force any core code modifications it can be
> added just like accessing files by FTP:, HTTP: or any other custom
> protocol.
If you stated the above as follow:
"Many thanks Miguel, for this kind contribution. May I suggest that we
make it more generic
by utilizing Virtual File Handles. Please let me know if I can be of
any help"
then it would be PERFECT constructive criticism. Surely you are intelligent
enough to understand that just because something could be improved it
doesn't mean it's "nonsense"!
> I'm sorry but there is nothing in above modification what
> can be even called innovative idea. I added request for virtual
> handles to Harbour TODO list for few years ago.
Time will be the judge, I'm willing to BET that this brilliant idea will
find it's way to Harbour, even if disguised by some trivial alteration.
>> For the Nth time, please try to be more civil and constructive, when
>> criticizing the work of others who volunteer their time and creativity to
>> this free project. They do not deserve to be ridiculed by you or anyone
>> else.
>
> I am constructive. I presented how it can be implemented without
> touching core code even as 3-rd party extension and I show what
> is broken in current implementation which is fatal and I should
> ignore it but I was afraid that someone may want to port this
> modifications to Harbour. Fortunately also other Harbour developers
> checked the details of these modifications and I do not have to
> longer worry about it.
No Przemek, you were and still are, really far from being constructive:
1. You forgot to THANK a ***volunteer*** for his initiative, time, and
creativity contributions.
2. You used and still use, offensive style and language, like "technical
nonsense".
3. You failed and still fail to recognized a great idea, and acknowledging
it's great potential.
4. You invented "technical" excuses, like "using CRTL which may not be MT
safe in some compilers".
5. You exaggerated improvement potential, as if it was some critical
deficiency (MT).
6. You failed to acknowledge even a SINGLE POSITIVE.
> And to calrify I perfectly well know what I'm talking about but
> I have serious doubts if you know what is real remote RDD if you
> called such technical nonsense as "brilliant idea".
Enhancing ALL core rdds to be Client/Server capable withOUT changing a
single line of code, is BRILLIANT even if a biased technical genius like you
denies it. The TECHNICAL FACTS are as follows:
1. Full Client/Server functionality.
2. Not a single coding change in all existing (and future) RDDs.
3. 100% compatible with ALL existing users code (AFAIK, the ONLY
Client/Server RDD architecture to guarantee this!).
4. As fast or faster than all existing Client/Server RDDs.
I have repeatedly acknowledged your impressive technical abilities, yet your
obvious bias seems to invalidate your otherwise unquestionable
qualifications. With all due respect, accusing this contribution of:
- "only replace transport layer"
- "using CRTL which may not be MT safe in some compilers"
does NOT appear to come from the same person we all know to perfectly know
what he's talking about. Instead this seems just another installment in your
ever lasting quest to offend and belittle some contributors.
Ron
------------------------------------------------------------------------------
_______________________________________________
xHarbour-developers mailing list
xHarbour-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
