Dimitris,
I would like to add my comments to yours, but I would like to address things one at a time.
>Since in the list of the new things of vfp 6.0, i didn't see any of my must list i decided to post the following:
First off, the list you have seen is what was released at Devcon last fall. I am sure there are many pther things being added besides those few.
> It is very difficult to be convinced, that the client server model could ever replace a file server model as VFP implements it, in cases such as single user desktop database applications, small to medium or departmental db applications, or generally applications that need quick access to data files in a lookup/navigational manner (i.e. point of sales, customer identification e.t.c.)
I would disagree with you here, the "navigagtional model" is a developer oriented model of seeing data and has nothing to do with point of sale or customer identfication. A real user in a Point fo sale situation does not want to be scrolling through 100s or 1000s of customers to find the one that is standing right in front of them. They want a rapid and simple search screen that let's them enter the name, phone number, driver's license number, or some other identifier that the customer has readily available and find that customer immediately, no browse, no grid, no list box involved.
>I also must admit it is difficult if impossible to imagine VFP as a replacement of a robust DBMS.
The folks who developed the logistics management system for the US Military that was used for Desert Sheild and Desert Storm might argue that point with you. Also the team that developed the security system for teh Eurotunnel might have some things to say as well.
>What is needed is a robust transaction oriented, database centric application development tool, which should contain:
>Real transaction logging capabilities for its local database machine but at the same time manageability (one could optionally select this capability)
VFP's transactions are fully imnplemented and do not fail to do their job on system failures. Of course if you ae using a file server then that file server might fail to do its job, but that is fully outside the scope of responsibility of the application running on the workstation. Using a database server instead of a file server is the only way to solve that problem.
>Build-in Encryption.
Bull ticky, encryption is simple to add on and it adds very little in additional security to the file server resource access controls except in certain special situations.
>Build-in Security (user,pass)
The entowrk has that and it si a breeze to add to vfp apps, every Fox app I have ever written since FoxPlus has user login security with encrypted passwords without using any addon product. No situation has been reported of anyone breaking the encryption in the last 17 years since I started using the encryption algorithm that I use.
>Speed, at least as foxpros
VFP has FoxProx's speed.
>Navigational character in manipulating its tables in addition with cursor support.
See above, I fully believe that this is an over rated issue be developer's because this is the way develoipers see the data. It is not the way the suers see their data at all and a lack of a grid or browse would not disappoint a user at all unless the search interface was inefficient or incomplete.
>Real-window windows and controls, but at the same time:
Why, as soon as the controls become "real windows" controls the inherent data binding capabilities go right out the window (no pun intended). ONe of the nicest things about VFP for developers is the natural data binding it has without righting code to get data from some place all the time.
>Ease data manipulation with data driven controls, that is enhanced controls in the way old db centric packages were enhanced (clipper, dbase or even cobol, don't forget we are talking about business type languages not a general purpose ones,… Just give a data entry clerk a mouse driven form, with no function key support …. )
This wish is somewhat in conflict with the previous wish, you can't have your cake and eat it too.
>Should we not use such a tool when we leverage the system in a c/s environment? Definitely not. Mostly, because most of todays applications would want to mix local data (i.e. Fox tables …), data residing in a legacy system (Cobol files) or data residing in a Dbms.
VFP already happily merges remote data with local data and the promise for the future is that this ability will get better.
>Such a system does not have to be named VFP if the language can not overcome some inherent weaknesses such as the dbf format, or the bitmaped based controls. It could be a VFP component for Visual Basic, or a SQL Server with a VFP environment, enhanced with the capabilities described above. At the other hand light editions of "Big Irons" (I heard something for SQL Server light) are usually driven to bankruptcy, most of them having not succeeded to provide anything but just a testing environment, due to their c/s character, manageability issues, or their failure to provide a means to develop real business applications with build in tools…
As I have said above the only folks who really find teh DBF format a weakness are those that have developed the code and techniques for exploiting the power of the dbf format. The unversalaity of teh dbf format is easily shut off by putting the table in a dbc with ingetrity rules. The dbc rules can even prevent the tables from being used at all unless a certain application is the thing trying to access them.
>If Vfp won't succeed to fulfill the void in this area, then we can be sure there are some old friends or some new ones, waiting to fill it (I show somewhere a database named "Navigational Database" …).
As I've pointed out throughout VFP meets the things you want right now, so what makes you thingk it won't continue to. The one thing VFP can;t meet is the "real windows" controls and that is in direct conflict with you desire for simple data binding.
>Nowadays everyone tries to convince us that we have to forget the business extensions in the tools or languages we are using in favour of the Internet extensions. At the meantime customers want their problems solved, and this is done via the old ways because improvements in tools that would help us in business applications are frozen due to the fact that everybody is concerned in making some funcy tool for extending internet technology. This is a kind of misdirection. Because it is impossible to extend the business in the Internet if there are still many localy "oriented" unsolved problems that keep shops from extending their role in the Net.
I don't see or hear anyone saying to forget the business needs, I do hear alot of people who are in a position to know saying that the internet and the intranet are technologies of the future because they put the little business on the same playing field with the big business. The internet opens the size of a market for a business at an extremely low cost. Customer's are beginning to check a potential vendor out on the internet first and if that vendor doesn't have a site, well they just may not get the business.
All these predictions and decsriptions are saying that if we, as developers, want to remain employeed and in demand over the next 5- 10 years, we had better get up to speed with the technologies of the inter and intra nets or else we will be left in the dust at some point.
None of this is saying that we need to stop all the development we are doing now and suddenly switch to web based everything. It is saying start reading, start expeimenting, start playing with web stuff, because if you don't you will find, a short time down the road, that you are among those saying "Hey, how come ther's no work for a BlahBlah developer. Every add for work says Inter/Intranet experience essential."
>After all, how many at the present time are making real money from the Internet ?
Many many developers are making very comfortable livings doing strictly internet work, and the number is going to grow as time passes. Right now one of the jobs that is very easy to get and is high paying is Web designer (that is with experience).
All that said, the line of business applications are always going to be needed. Those apps may or may not be directly related to the internet. But I feel very confident that those apps are going to find a requirement in their specs that says certain output and input opreaions must be capable of being accomplished on teh internet showing up gradually over the next few years.
