I've talked with some attendees of your conference and I noticed that they really enjoyed it. How about you? The conference did reach your expectations?
Yes, the conference was excellent. The level of sessions presented was very high and the speakers did an exceptional job of presenting a variety of topics.
How do you feel about having people advocating the use of a product such as yours? I mean, people like the ones at DNG Solutions (which is an ISP specialized in Web Connection), Randy Pearson (who's aimed to produce a tool based on Web Connection), and also having a book written by others about the use of your product. You know, you can say that these guys are making good business with a tool that you had produced. Are you proud of your son? <s>
Well, what can I say, but that it's great <g>. I'm always surprised how far reaching Web Connection has become over the years. But given that there are so many people are using this tool it's to be expected that related tools and services are springing up. It's exciting to see that so many other people can take the tool and build ontop of it. It's especially rewarding to hear people mentioning that the tools have changed the way they work with some people working on Web Connection applications exclusively.
But ultimately its more than just me that is responsible for all of this success. It's Visual FoxPro really that has made all of this possible and the active West Wind Community that's involved and provides support to peers. This conference is made up of peer developers and I hope that the attendees felt it as such and had the chance to participate with input. A lot of that IMHO is responsible for the enthusiasm I often see among our customers.
During the conference you said that WC's users may expect some new major version after the release of VFP 8, if you find some good advantages by doing that. From the top of your head, did you already have any good idea about what sort of feature you may implement in WC thanks to some new stuff of VFP 8?
Well, there are obvious things like integrating TRY/CATCH, the XMLAdapter into the XML classes and potentially using the CursorAdapter in the business object classes. But there are many small things as well much of what you'll see at the GLGDW conference. Above that WWWC is based largely on a VFP 6 codebase that has been enhanced extensively with VFP 7 functionality - there's still a lot of code in the framework that could be reworked to use VFP 7/8 features to provide less code and slightly better performance. I think a VFP 8 version would allow to remove some of the 'legacy' code and bring the framework up to the latest version without having bracketing for VFP 6.
Talking about VFP 8: what do you personally liked the most in this version?
There are many think in this new version that are things that I've requested for a long time. TRY/CATCH is certainly at the top of my list, but there are also some things that you might not expect from me like support for Themes, and improved menus and toolbars, the new BindControls property (which allows forms to not bind data until you tell it to) that for a number of applications I have saves tons of code. The XMLAdapter is also very cool, but I have to figure out how to retrofit code in order to utilize it. There's tons of cool stuff - it'll will take some time to take advantage of this stuff in existing applications frameworks, but for new apps the majority of new features can be of huge developer value right away.
A big number of VFP developers are going for Web developing with ASP.NET and VFP COM. I think that the main reason for this is the object orientation of ASP.NET, as well as the handy visual editor in the VS .Net. With that in mind, how do you intend to keep and get new developers using WC? Are you planning doing any integration between WC and ASP.NET, maybe using WC as the server and ASP.NET as the facade, making use of its productivity and code reusability?
I don't think ASP.Net changes things much for VFP developers in terms of making development with VFP easier. In fact, in many ways ASP.Net is more difficult to use with VFP than ASP was because of strict typing. Native ASP.Net provides many improvements but the COM story is actually worse in more ways. Performance of ASP.Net with COM is significantly less than with classic ASP and the debugging story hasn't changed any. Strict typing makes it very difficult to deal with dynamic objects returned from COM objects which is a big issue if you have hierarchical object that you are dealing with which is common in business object frameworks.
I also think that those VFP developers that are set on ASP.Net will soon discover that it's easier to use .Net native languages than trying to interface with VFP and loose most of the benefits that VS.Net offers. I'm not saying htat people should switch to .Net but if you want to take advantage of ASP.Net to its fullest you really need to use the .Net languages. And even if you call VFP you'll find you'll have to know a lot of .Net - you figure it out <g>
I think a tool like Web Connection continues to cater to VFP developers who want to use VFP primarily to perform their Web development. And developers aren't stuck in a single environment and can decide which tools will fit the bill for them including VS.Net for their editing tools. Many of the things that ASP.Net offers have been part of Web Connection for years and only now are available to a 'shrink wrapped' product from Microsoft.
Judging by the continued and maybe even increased interest in Web Connection over the last months since .Net has shipped is a good indication that VFP developers are still interested in VFP specific solutions that they have full control over. And maybe it also indicates a certain frustration level with the .Net learning curve <g>
In your opinion, what's the advantages and disadvantages of building/consuming Web Services in the following environments: VFP with SOAP Toolkit, VFP with WC and ASP.NET XML Web Services?
Frankly I think that ASP.Net Web Services with .Net clients are hands down the easiest environment to build and consume Web Services. The mechanics and implementation are so well integrated into the development environment and exposed just like native code that it's hard to find any fault of the .Net implementation especially for consumption. The server side pieces too are single step integration - no separate steps to keep WSDL files in sync and deal with type issues that are plaguing COM and VFP based SOAP solutions.
The question is just whether you can afford to be using .Net for your application that uses Web services. For most VFP people that answer is likely no.
The MSSOAP toolkit requires too many steps and there are too many things that can go wrong. VFP 8 makes this a lot easier actually by the built in Wizards, but there are still many limitations like the default reliance on the FFC classes for example. The problem is that it's fine if it all works the first time which is highly unlikely given the configuration parameters. Then you're all of a sudden stuck with having to figure out system level debugging procedures to try and get an idea what's happening. This is not acceptable.
Web Connection's SOAP and Web Services implementation is not necessarily meant as a separate platform and I wouldn't recommend it for people who are not already running Web Connection in the first place, because you'd have similar issues than the MSSOAP toolkit there potentially (albeit better documented <g>). However, if a Web Connection developer already has a Web app running and wants to add Web Services to the app it's a snap to do. If the rest of the app runs assuming the Web Service code runs without errors the Web service will definitely run by simply creating a class. And if they are doing VFP -> VFP SOAP code they do get easy access to complex type passing without having to do anything extra.
The advantage I see with Web Connection's classes is that they are not black box code. We can fix problems and new additions to the spec and work around any issues that occur during calls. If you get back something from a slightly non standard Web Service (something that happens frequently BTW) you can work around it easily enough with custom parsing code which is not possible with MSSOAP. I can very easily debug wwSOAP client requests by looking at request and response strings. So if I get an error from the server like a 400 authentication error I don't get 'Unknown Error' as the SOAP toolkit does with most errors.
However, the biggest problem COM and VFP based SOAP/WebServices suffer is the inability to deal seamlessly deal with complex types (objects/structures/Data etc). Web Connection's SOAP client has ways to deal with this but it's a hack at best, because COM and VFP can't easily expose type information accurately in a self-contained format. That's unlikely to change so we're stuck with hacks... I'll be the first to admit too that it's increasingly difficult to keep up with the ever more complex SOAP and WebService specs coming along especially since most of them are very badly suited for mapping to VFP/COM classes/methods. We'll have to seehow this pans out in the future...
In the GLGDW 2002, Microsoft's Ken Levy announced you as this year's "VFP Lifetime Achievement award" recipient. Congratulations! What do you think of this?
Thank you. Well, it's an honor for sure, but I don't know if there aren't other people in this community that have more of a 'lifetime' achievement than me. I do what I do out of self-interest and as it happens that's been beneficial to the community. So the award came as a bit of a surprise to me...
I know you said that you are not intending to build a WC .Net version. However, don't you think that you could come up with some good ideas for a framework that could wrap or extend ASP.NET, giving even more power and flexibility for the developers?
Well, Microsoft blankets functionality. ASP Classic didn't have a framework, but ASP.Net *is* a framework, plus a development framework underneath. It leaves very little room to maneuver for third party expansion. I think we'll see lots of small specialized tools to fill little holes, but I also think many of these are likely to get plugged quickly by Microsoft. The other is one of business model. The perception is that if you use .Net you 'use the framework' - you use what's there. We have mostly early adopters using .Net to date and those are not terribly interested in getting a helping hand. As more people migrate that'll likely change, but even then I suspect most people will try to build their own. We'll have to wait and see. For now, I've been focusing on smaller tools and some applications as I myself have been learning .Net. But I also have no plans on leaving VFP behind as I continue to feel that VFP apps can be built in a fraction of the time that it takes to build .Net apps including ASP.Net apps. For all but the biggest applications that must serve 10's of millions of hits a day (in which .Net hasn't proven itself yet either) I consider VFP a capable tool. Especially for Web apps with WWWC I can be so much more productive than I can ever expect to be in .Net because of VFP's language features.
For closing this interview, I must ask you a question that all the community are asking worldwide: Where's Rick Strahl's long hair?!? (I've also heard something like that when I've cut mine six years ago) <bg> Have you been attacked by a crazy wife/girlfriend (as I was...)? <bg>
Nah, it's just time to change. You know you can rock just as hard without the hair <g>... Long hair is a pain in the ass for sports which is what I'm most into at the moment. Nothing like having your hair frozen solid in a long string in front of your face coming off a cliff on a snowboard...
Thank you for this great interview and congratulations for your great WC's conference and Microsoft's Award. By the way, I brought my guitar to the US; let's do some jam session anytime. <s>
