In the VFP community, there's a consenses : Rick Strahl is the first name that comes to mind when people think about VFP and web-based applications. Playing with web-technologies for the last 7 years, he has gathered expertise in the development of web-based applications, using mainly Visual FoxPro, and that's consolidated in a wonderful framework called West-Wind Web Connection.
Besides that, he's also a very good writer, giving us many good white-papers, articles an amazing book about VFP and the Internet.
Why VFP?
Why not? <g>
How long ago did you start to build Web Applications, and when did you realize VFP was a good tool to do this?
I started Web Development with VFP sometime in '94 when I had the original idea for Web Connection and a Web framework specific for VFP. At the time I didn't think about a commercial product - it was something I thought would be fun to play with. As the framework took shape I ended up getting a couple of consulting jobs to build Web applications and the power of using VFP as the backend over the tools available at the time became readily apparent. This was at a time when there was no ASP, or even the Internet Database Connector - Microsoft hadn't even started with a Web strategy at the time.
I was able to build large apps in a very short timeframe using standard development tools which at the time was really unheard of. One of the early sites was the Surplus Direct and Surplus Auction sites which were at the time amongst the top 50 Web sites on the Web and they were running using Visual FoxPro as a backend on relatively low end hardware taking in excess of a million backend hits a day.
As time went on things kept getting added to the framework and eventually it turned into a commercial product. Although Web Connection made a lot of this possible, it's really the power of VFP that makes the development process so much easier with just about any other tool. Even to this day I think that VFP on the backend is a great Web development choice.
WOW! Back in 1994 was the time when VFP was first being launched with Windows 95. At that time, neither IDC, FoxISAPI, nor VFP COM even existed! How did you develop for the web with VFP?
Yeah, funny, huh? Web Connection started out on VFP 3.0 and has made it through 5, 6 and now 7.0... Really Web Connection as a product didn't come to be until late in '95 I think.
You were "hiding the gold", huh? <g> The main question is: How could you do web development before 1995, without any appropriate tools? What planet did you come from? <g> Sometimes I think that you, Markus, and some other people aren't from Earth because you're so many years ahead of most developers! <g>
Nah, nothing like that. Plenty of people were doing Web stuff back then just not necessarily with VFP. It's just a matter of adapting something and expanding on it. But even then there were a few other people like Michel Fournier who were working on Web projects also using hacked together tools. It just wasn't that visible back then because nobody really cared at the time.
Your main development technique is based on FoxISAPI, that as far as I know, is much faster than ASP. However, you keep using ASP on your web site. Why not use only FoxISAPI?
Web Connection was never based on FoxISAPI. In fact Web Connection predates FoxIsapi by several years. The technology for COM based operation is similar to FoxISAPI, but it's not in any way based on the source code from it. ASP is faster for a lot of things than going to a backend like VFP as long as you don't have data access or call into a COM component. Plain ASP, wihtout COM and data access is almost as fast as using static HTML pages. THere's no reason to call a Web Connection backend if all I want is a counter on a page or track users etc. I think my site has only 2 ASP pages that do data access - one is the search page using Index Server and one sample page that uses a Web Connection back end as it's SQL data source via HTTP. All the other ASP pages on the site (most almost 'static' pages) don't do data access or anything other than dealing with counters and user tracking.
When I said "based on FoxISAPI", I meant that it relies on it. That's what I understood from your book. But if Web connection came before FoxISAPI, what is the exact role that FoxISAPI plays in Web Connection?
No Web Connection has nothing to do with FoxISAPI. It was kind of funny, when Web Connection made the switch from file only operation to also supporting COM operation, Calvin mentioned that he'd been working off another internal Microsoft tool (OLEISAPI) and updated it to become FoxISAPI. Both our versions arrived within a week of each other or so and we compared notes <g>. Totally separate code base although I looked at OLEISAPI myself too to figure out some of the COM stuff. That's some really hairy code and it took almost a year to get COM operation stable in Web Connection.
Talking about FoxISAPI, we always hear that it's not officially supported by Microsoft. However, a few weeks ago, when this question was raised on the Universal Thread, Microsoft's Mike Stewart answered that he is supporting it. Do you know anything about this?
I'm just quoting what it states in the documentation. It's great that Mike is supporting it, but officially Microsoft's stance is that it's a non-supported sample application.
One of the main mechanisms of Web Connection is implemented using Randy Pearson's CodeBlock and your VFPScript for pre-compiled pages. With Web Connection 4, you are doing some amazing things between Text to Memvar and StrExtract and ExecScript (new feature in VFP7) aren't you? If so, how much faster is Web Connection now?
Most of the improvements above come from suggestions several developers including myself made and Microsoft has taken those suggestions and moved them into VFP, which is a pretty good indication that the VFP team definitely listens to developer needs. Many of the features now native in the VFP 7 are extremely useful, but they're not necessarily much faster. For example, ExecScript is slower than Codeblock in many occasions. TextMerge to string is not a lot faster than doing the same thing with Fox code by going to file and then reading it back in. But it's definitely nice to have those things included in the language.
That's interesting. Could you give us more details?
If you have small blocks of code that don't loop extensively, CodeBlock is almost always faster. There's a lot of overhead in copying the code to disk, compiling and running it which is what ExecScript does and that overhead has to be made up before ExecScript starts outperforming Codeblock. ExecScript is nice though because it's real easy - it's a single method call. Codeblock requires setup and some sort of wrapper usually.
Personally if I want better performance of scripts I just pre-compile them - that way you get the best performance you can possibly get. You can even do this with dynamic code stored say in memo fields of a file. In Visual WebBuilder Markus designed it so that codeblocks would precompile and store that data in a memo - we'd then run the code from the files on disk which would be dumped out once and cached. So we got the best of both worlds there. It works, but this kind of setup requires all sorts of admin overhead.
It all depends on what you need - speed or easier maintenance. If you have a standalone app that runs few requests with dynamic code it isn't going to matter much. but if you have a Web app which gets a few hundred thousand hits a day you better be careful with your choices. Anything that dumps out to file is dangerous in that kind of high volume environment because of file naming issues and the volume of files being created in the directories.
One feature that does provide major, major performance improvements is CursorToXML and if you can use it, XMLToCursor(). Both of these offer huge performance gains over what you can do with native VFP code.
Comparing these XML native functions to your wwXML, which one has better performance?
Native code is almost always faster than anything you can do with Fox code. CURSORTOXML and XMLTOCURSOR are *a lot* faster than wwXML used to be. In the latest version wwXML actually uses CURSORTOXML to generate XML in many situations which makes it almost as fast as the native code. wwXML adds a bunch of functionality that CURSORTOXML doesn't have like the ability to name elements and support different schema and DTD generation. Unfortnately, I wasn't able to make XMLTOCURSOR() work the same way - it's too dependent on the XML document and schema itself. It works great and blazing fast if you use both CURSORTOXML and XMLTOCURSOR for import and export. But if the data is generated elsewhere and doesn't include the same schema as CURSORTOXML generates XMLTOCURSOR guesses at the structure of the document which results in sometimes unreliable results for a generic function.
So to answer the question, VFP 7 has helped in a number of aspects of performance in Web Connection, but it's not a stellar change, and won't affect overall performance drastically. It's made some code a lot simpler, but then again WWWC still supports VFP 6 as well so the original code is still in there as well in bracketed blocks.
I'm sorry, what do you mean by "bracketed blocks"?
#IF VERSION(5) = 700 do VFP7 Code #ELSE do VFP6 code #ENDIF
Microsoft's .NET framework claims to be their solution for the web. Will you personnaly be developing in .NET?
Sure, I'll use it for what it does well.
And what does it do well?
Really large scale apps. Web Services.
You have to use new technology whether you plan to make it your primary development tool or not. You have to understand what it does, what it's strengths and weaknesses are in order to know you're using the best tool for the job.
That said, I still believe VFP is a better choice for me for Web Development. .Net has a number of cool features and the underlying technology is finally optimized for the Web, but as far as business solution development goes I believe that hte framework is not nearly as flexible as some of the things you can do with VFP with ease and very little code. .Net is complex and will require serious relearning for anybody no matter whether their VFP, VB or C++ programmers and for developers coming for 4G language (4th generation language. VB, VFP etc. are 4G languages) will mean *lots* more code to write and maintain. Over time this may change as add-on frameworks may simplify .Net, but for now you have to commit to a huge chunk of time to learn and work with .Net.
VFP's strengths continue to be a very flexible language, super easy data model and the ability to dynamically access just about anything in the language and the environment. The code, debug, deploy cycle in VFP is a fraction of what it takes in other languages and I don't see that changing.
We already know that VFP can also scale for Enterprise Web development with apps on a single box having topped out at over 5 million backend hits a day in one day. Unless you're building a Yahoo scale site a VFP solution will be more than adequate...
Let's say that I have the need to build a site that is the size of "Yahoo". In your opinion, what tool should I use?
Well, .NET is supposed to address that. Today you can do this with COM but it may require a lot of scaling out to multiple machines. .Net supposedly is more efficient and able to better use machine resources to allow keeping bigger apps on a single box. It also makes scaling out, when needed easier with built-in tools for dealing multi-machine operation. Nothing you can't do with COM etc. but again a lot of that stuff is built-in at the system level with .Net where it needed to be built by hand or from a third party (such as Web Connection <g>).
Whether performance is really as much improved as Microsoft claims remains to be seen, but tests on pre-release builds certainly seem to point that indeed perfomrnace is much improved.
Since you are generally known as the worldwide VFP Web Development authority, have you built any desktop apps (besides administrative ones)?
Sure. In fact most of my products have a desktop component that goes with them (the Web Store has an offline order manager, the Message Board has an offline reader) and West Wind HTML Help Builder is a desktop application altogether.
I think desktop applications are way more important than people think. They won't go away by any stretch of the imagination. On the contrary. Web Services and distributed technology will make it so much easier to Internet enable desktop apps that there will be a huge surge to improve existing applications without converting them into HTML based apps.
Very good point. There's a lot of people who are so eager to have the "state-of-the-art app", they expect just HTML based apps. They think that desktop applications are "an old story"... and it's useless to tell then about web services and distributed technology... they want to open a browser and see their apps running. What could you tell about it?
You have to sell the idea possibly. Just like any app there has to be a reason for going with one interface over another. HTML works well if the user interface is relatively simple or the app can break out the user interface into smaller pieces (ie. Wizard like interfaces for complexes processes or inputs).
Desktop apps are still much, much easier to use than Web apps and provide a much better user experience.
We know about your expertise with VC++, that you even fixed FoxISAPI's bugs. Do you think VFP developers should have VC++ as one of their basic skills?
I hate C++ <g>. Like Markus says: Life's too short to code in C++. I guess Microsoft must have realized that when they created C#, huh? But it's a good skill to have. I use C++ a lot actually to provide OS services to many of my apps. I figure it's easier to write the code in C++ than try to make VFP call into complex APIs with types that VFP doesn't support directly (although you can use some tools that help with this like Christof Lange's STRUCT class).
What kind of OS services?
Like dealing with security. Calling Sockets. Calling COM APIs. Calling third party APIs (like credit card validation interfaces, real-time hardware interfaces etc.), writing an ISAPI extension. Heck there are a million things...
You build FoxCentral.Net jointly with Microsoft and the Universal Thread. Do you personally think that Web Services are really the next generation?
I've been building distributed applications for almost 5 years now and yes I believe that distributed applications are the wave of the future. You can do so much with this technology that enables existing applications without throwing away old code. SOAP and Web Services is just an extension of that technology as a whole and it's pretty immature as of now with the big players mucking around too much with the standards. But SOAP has come a long way in a relatively short period of time and industry support is there.
Once you build a distributed application that pulls data off the Web with a 'real' use (ie. not a demo) I think you'll find yourself a believer. My site is enabled in this way in so many ways and I can get data from it in a variety of ways - the process of building HTML and distributed interfaces in my apps pretty much goes hand in hand these days. I think you'll see this concept becoming more mainstream over the years. Most people just haven't really thought about the implications that using the Web as a network and the Web Server as an application server for data really brings.
There are issues with all of that too, though. Finding a pay model for providing services and dealing with security and dependability. For this reason I think the first wave of Web Services will be internal - sort of like Web based APIs to existing applications and services that people pay for and get the Web Service as a bonus.
What is the main difference between your wwSoap and MS-SOAP Toolkit?
wwSOAP is built with VFP code so it's more flexible in a lot of ways. MSSOAP works fine when it works, but if you have failures it's becomes Pain in the ass. You have to wrap MSSOAP to make it work properly in failure scenarios. MSSOAP also doesn't deal very well with complex types, which is pretty important for calling .Net Web Services. wwSOAP gives you full access to everything in SOAP package so you can decide how to retrieve data (as native data types, as XML strings or as XMLDOM objects) so even if the data that is returned is in an unknown format you can use it (try returning an object from an MSSOAP request for example). MSSOAP lets you do all that too but that API that provides for this is rather twisted in its implementation.
wwSOAP also uses the .Net model optionally of creating a proxy object that basically provides a real VFP client object wrapper to allow for Intellisense and the ability to override functionality of the method calls on the client side. In fact, the proxy can work either with MSSOAP or wwSOAP.
On the server side Web Connection Web Services are implemented as script files or native Web Connection process classes (there's a special WebServiceProcess class which is faster than the scripted version), which allows you to do the Web service development completely in VFP code including live debugging and error handling. If you use script files these files are compiled on the fly and can detect changes to the file providing good performance. The process apporach is a bit faster and uses the standard Web Connection programming model of a class inside of a Web Connection application which can be fully debugged as well, but requires a recompile on change. The server side really compares ASP COM programming with all of its intricacies and configuration headaches vs. using Web Connection's VFP centric model
Could you tell us the main differences between Web Connection and other products for building Web Apps with VFP?
I don't think I can get you an objective view on this. Frankly, I don't look at the competition all that much. Seriously though, the other products all have their place, but I believe that Web Connection is the most complete framework that provides all the tools you need to build a Web or distributed (client and server) application with VFP. While other tools address a few of the development needs Web Connection handles most of them as part of a single package, so you're never locked into a specific way of doing things.
I'm often asked what is the best way to develop web applications with VFP. What is your opinion about this?
Again, I'm too biased to give you an objective view of this. All I can say is that all of my apps are built with Web Connection and I wouldn't think about using anything else. Believe me if there was an easier or more efficient way (to me at least) - I'd be using it. I'm developer too in addition to selling product, so I work on applications as much as on product development. Anything that can save me time I'm interested in <g>...
What do you think is the best way to pass data through the layers of an n-tier distributed application: ADO RecordSet, XML, or some another?
It depends on the application. A good application framework should handle data in a way that it can adapt on the needs of the application. Personally I like to pass data in a COM based application using objects (data properties on objects) and object hierarchies. For bulk data, object arrays if the data is small, or XML or ADO if the data is large. It all depends. I believe in disconnected data so it really doesn't matter much which mechanism you use... With VFP 7 XML is damn good way to pass data with relatively little overhead now so that the need for ADO really is minimized...
Over the Web - it's XML for sure. I like to pass persisted objects over the Web as XML whenever possible to allow true object -> object mapping between client and server applications. For larger sets CURSORTOXML/XMLTOCURSOR will do the trick although in Web apps sending large chunks of data should be avoided as much as possible instead relying on retrieving data in smaller pieces...
Let's talk a little about load balancing. In your book, we've read about FoxISAPI pooling, and also about MTS... using MTS (nowadays COM+), we have some services, that I don't know if we have in FoxISAPI.
For instance, I've read your CoDe's article about a way to build a class such a MSMQ, but better. What do you think about all of this? I mean, there's a lot of technologies out there, and Microsoft make us buy their ideas, but a lot of times, we can do better stuff, and when it worths and when not...?
Tough call. A lot of things in COM+ look good on paper, but they're a lot harder to implement than what it looks like. A lot of extra work needs to happen to take advantage of COM+ and the developer really has to know what he's doing. Some things are easier than others, but as many things coming from Microsoft, I think a lot of the OS stuff is too difficult to implement. There's no reason to have so much complexity in things that are essentially simple processes.
MTS/COM+ 'load balancing' is one of those things. Especially since it doesn't provide any load balancing directly (Component Load Balancing is actually an addon that comes with Advanced Server and Applicatino Center). The ironic thing is that COM+ was supposed to provide some load balancing services and COM+ did introduce a pool manager as part of the base services - but they don't work with components built in VB or VFP. And of course those components are the ones that need it the most. An efficient, truly multithreaded C++ component has much less need for a pool manager than a single threaded component built in VFP or VB.
Again, Microsoft is addressing these kinds of issues by providing native multithreading support in .Net as well as tight integration of COM+ into the CLR languages. It's a little strange though that .Net is not in any way associated with COM *except* for Component Services which is basically the .Net COM+ integration. To take advantage of COM+ .Net actually wraps .Net components into a COM wrapper which means there's a performance hit for using COM+ services. Over time this will likely change, but for now, technology is overlapping.
As far as duplicating or extending functionality that MS provides goes, there's a simple pattern. Sometimes it's better to build a custom solution for a job especially if it can be done with relatively little code. The Async manager class I built is essentially a toned down message queue, that's optimized for random access, which Message Queue is really bad at (slow and no easy interface to retrieve messages in a non-sequential manner).
That's part of the point though - it's so easy to build powerful solutions in VFP with very little code, that it's often a no-brainer to rebuild some tools that are a better fit than Microsoft's generic solutions. In the case of the Async manager I got much more flexibility and slightly better performance for the random access interface I needed to build.
Another question about COM+... things in VFP7 like Loosely Coupled Events, Queued Components and other features, really aren't necessary are they? I mean aren't that "beauty painted elsewhere"? Indeed, I didn't see many people who really rely on Windows DNA...
I don't think so. COM+ has its uses but I think they are relatively specialized. Some of the things you can do with COM+ are extremely useful when you need them. Then again somethings in COM+ are complex and require a fair amount of code that could potentially be built much easier and in a more controllable environment.
For me personally I'm not a big fan of OS provided black box code because if something doesn't work right with the black box there's usually no workaround. This is one reason why I'm worried about the whole .Net thing - which is even more of an extension of the black box especially for Web development. Just today I'm working on some .Net Web Services stuff that just stopped working all of a sudden. Client code in the IDE just locks up when calling a Web Service, but it works fine if you run an EXE. There's no way to debug or fix the problem because it's all in the bowels of the OS. Some say that's a good thing so you don't go around re-inventiing the wheel, but I often like to invent my own wheel because it gives me control over the solution. At least give me source code so I can trace through the problem and possibly fix or work around it. The same rules apply with COM+...
You're used to sharing your expertise with the VFP community. You always make a lot of stuff public domain such as wwIPStuff, wwXML, wwSOAP and a lot of wonderful and useful articles. Here there are some people who ask for payment to teach someone how to make a simple Splash Screen. What would you like to say to those people?
To each his or her own. I give away stuff in hopes people will buy the products that aren't free. If it's something useful, I think it's fair to charge for it. If you don't think it is - don't buy it and build it yourself.
I think it's important to share code and the spirit of it will help everybody in the community. Ultimately it'll come back around to you when you need some code yourself from somebody else. The VFP community in general is much better about this than any other. There's a lot of free stuff and tools and samples around that are actually useful if you take the time to look. That's a good thing and there's some satisfaction in knowing your code might help somebody else out...
Changing the subject, in my interview with Markus, I asked him about how both of you handle your egos working together on projects. (Since you both are "VFP Rockstars!" <g>)
He he... Who says we get along?
We actually don't work together all that much. I like to work on my own, but when we do work together it's like any other joint project - we work together. We do work together well - it's a good fit because we're good at different things.
Talking about Rock, my band needs a Bass Player; would you like to play with us? <g>
If you fly me to Brazil - sure <g>...
Rick, I'd like to thank you a lot for taking the time and sharing this information! This interview was really amazing. I still hope to see you and Markus doing a Double Impact Tour here in Brazil.
Well, that's up to you <g>... we need somebody to set it up...
