>embedded smtp controls
>embedded ftp controls
>embedded imap controls - not pop3

You can buy controls to do this sort of thing today. IMO, having your pick of diffenent controls is far better than having the kitchen sink bound into the product.

>
>save to mem, would create xml files not .mem file and restore from mem would read by xml files. into memory, no xml files into cursors.
>

Interesting idea. However, I would then ask what the value of XML files is over a MEM file, other than the fact that it is open and readible by a text file viewer.


>
Without having to open up IE, give the ability to read a prefdefined web page, and have a html parser to extract the important data from inside it.
>

Isn't this what XML is for, to separate data from HTML? How is this in the province of VFP? I think it is up to the page designer to make the data accessible, not for VFP to figure out a way to fetch the data. Of course, if the page is pre-defined, you can stream the HTML yourself and parse through it to extract data. The fact you have to use IE, I don't see that as a big deal since the core IE components are always availble.


>
The sql upsizing wizard should be able to read whatever odbc / dsn records are stored on the machine, and then give the ability to upsize to anything which is connected to that machine.- not limiting the upsizing to MSsql only. (I know I am dreaming here)
>

As soon as the word Wizard comes into play, I always get skeptical. The upsizing wizard has never really worked. I contend that no better approach exists than the manual method of handing these sorts of tasks..


>
What I am thinking about is, because VFP is now out of the .NET. in order for VFP to survive, it needs to meet a specific function not currently met by other MS produts.
>

Ironaically, it already has specific functionality not met by other MS products. It has been this way for quite some time.


>
VFP could become, not only a network, desktop application, but it could be used a hub, in an enterprise, collecting, extracting data, from all sorts of different datasoruces, and publishing back to the users, in the form of html, xml, sql, etc.
<

I think VFP is already there today...



>
i.e. if you get an email daily with an attachment, of say an execell file, that file has say inventory on it. Your job, is to trap that email, convert it to a sql server, and publish it on the web. While that is acheivable, today, the amount of aftermarket addins, to get it working, is mindblowing. while if VFP could read an email, then the rest of the conversation would be done, automatically.
>

I bet there are dozens/hundreds of VFP applications that do something similar to this already..

<<
>Same thing with a newly published ftp file, a supplier could update their inventory, or price list file daily, on their only ftp server, VFP could then, check for the update say every few hours, and extract it, and republish it in whatever format was necessary...
>
>It could be that I am the only one, who has these types of requirements to deal with daily, but I dont think so. Reading the posts here, it appears, that data is comeing across our desks all the time, in various formats, and we all need to consume that data, and republish on a regualr basis.
>
<<


Everything you suggest here is doable today. It is a matter of writing the code.