Hi Przemek
First of all thank you for your time.
I agree with you in almost all you've said.
Sometimes is good to stop and rethink where we are going as a community.
So far the last year has been VERY productive and the new tools and
features (hbmk2, netio, threads) have improved que quality of the
product 100'd times.
I'm also happy that people like Roberto Lopez are joining the
discussions. He has a very clear vision of how a clipper compatible
product has to be from the cliperhead point of view.
It's not easy to join c-oriented heads with 4th or 5th level programmers
( scripting kiddies if you like to name us like that ).
Przemyslaw Czerpak escribió:
On Mon, 12 Oct 2009, Angel Pais wrote:
You're failing the comparison point.
Meassuring apples against bananas.
We cannot compare gui applications against console apps.
I do not compare user interface at all.
I compare only simple IO operations in SEEK or SKIP which are
the same in GUI and CUI application. The same reports created
by application under WINE control are over 10 times slower.
Agreed. An be sure I will get rid of wine as soon as I can.
The time is important only in long operations. In the rest is not
important at all. At least is not visible for users. In current
days it doesn't matter it's CUI or GUI application. In both cases
the code is executed fast enough to work interactively without any
problems. User can see the slowness only when he tries to collect
some data from tables and such operations needs some deeper analyzes.
And here the speed overhead in WINE is the biggest one.
If you execute pure .prg code, i.e. simple FOR/NEXT loop then code
in WINE works with the same speed as native applications. Just execute
speedtst.prg compiled as native application and as windows application.
It's even possible that the windows one will be a little bit faster.
But if you try to read or write from/to files or sockets then you will
find that code executed by WINE is very slow.
Agreed
RDBMS does not exclude using DBFs as storage format.
ADS is RDBMS and can use DBFs. I've never understood why Clipper
users used to think that SQL == RDBMS and DBFs != SQL or DBFs != RDBMS.
These are three different things which can be used in one product or
in separate products. It's quite easy to add SQL support to DBF tables
but it will not convert the program to RDBMS. Just like RDBMS can use
DBF format to store data because unlike common opinion said it's one of
the most efficient data base formats in many situations.
I know that. I said dbf as I could've said sqlite, mdb or any other file
based methodology.
The serious candidate for this is uhttpd but the are missing a protocol for
serialize-transmit-deserialize data in a 2 way relationship.
I rather suggest to write simple RPC server from scratch.
Using HTTP protocol and some universal HTTP server is not
very good idea. At least it will be very inefficient in some
cases and you will have to deal with many of problems caused
by sateless protocol like HTTP.
Very interesting !
Just my humble oppinion about our technological status.
Let's work all together to improve this marvelous plattform instead.
My hat off for this great meeting of great programmers Harbour has earned.
In some spare time I'll write simple RPC server for Harbour.
Maybe you and other users find it interesting.
For sure !!! It will bring a new world for us, all clipperheads.
My best regards
Angel
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
