Feature Interview: SoftVelocity's Bob Zaunere

Posted March 12 2001

Printer-friendly version

Bob Zaunere, SoftVelocity's President and CEO, recently spoke with Dave Harms about the Clarion product line and SoftVelocity's plans for the future.

You shipped Clarion 5.5 last November. What has the response been like?

Clarion 5.5 has been really well received. We get a lot of email from people who are really happy with the stability of 5.5, and who are pleased that the product they'd waited so long for was actually delivered. There were areas that we just couldn't address that we had planned to address, but most of them we were able to get to.

It was a long wait between 5.0 and 5.5.

TopSpeed was ready to release 5.5 just about the time of the transition [of Clarion ownership to SoftVelocity]. I held it for a lot longer than most people thought I should, including a lot of the Development Centre. I was catching a lot of flak from people who said "Just ship it." I said no, we'll ship it when we get enough feedback that it's really stable. And it shipped as a very good, solid product.

Is the time between 5.5 and 5.5a about what you expected?

I think so. We started shipping 5.5 at the beginning of November, and then before you know it you have the holidays and that affected everybody, so essentially we had about three months to turn this release around. In that time we weren't strictly just working on bug fixes. We've got to continue to develop new projects as well as enhancements, some that began as long as two years ago, so I'm pretty happy with the delivery of the first release in that timeframe.

Do you plan to release no-cost updates on a regular basis?

That's part of the strategy. Things that need fixing will be fixed, and there will be no charge for that. If we start talking about enhancements, they'll either be delivered as a full version release (5.5 to 6) or as a dot release. I lean more towards saying if we can come out with major maintenance releases on a three month cycle, or sooner, depending on the scope of what we want to fix, and come out with dot releases two per year, and maybe a full version release every year, I'd be pretty happy.

You've been getting some heavy hits on the 5.5a update. Do you have enough capacity to handle the downloads?

We host with a company down in Miami. We were really pleased with their performance, but they recently did a major push to get market share in Latin America, and they added 10,000 new customers. So I think we may be looking to host with another [company]. They claim to have gigabytes of bandwidth, but seeing is believing.

Is all that traffic an indicator of Clarion sales?

New license sales have continued to both make us happy and amaze us. We sell quite a few new licenses per month, and we expect that trend to continue.

How's the "sell with them" approach to marketing going?

It's worked really well, and that's reflected in our sale of new licenses. We have some work to do in that area, and what we plan to do is to offer some free web seminars that will introduce people to the product and what you can do with it, and just make the seminars open to anybody. Short little things, maybe twenty minutes or a half hour, either on-line or downloadable, and [we'll] let them get distributed.

One of the new features you have in the works is more direct support for SQL. What will this look like?

The basic premise for the SQL product is to directly support the use of the SQL language, static or dynamic, using PROP:SQL for all queries, updates, and deletes. The advantage we see with this is the resulting code is very easy to read and extremely easy to optimize.

Is this a rewrite of the ABC browse?

It is entirely separate. It is not an extension or add-on [to the ABC browse]. It is strictly its own beast.  The reason behind it is twofold. One is that the code for a browse is not trivial, to say the least. It doesn't have to be [that complex]. If you can take away some of the code and put the logic onto the backend, you can really simplify what the code looks like. The other reason is performance. Our driver technology can really perform well given the right circumstances. We have more and more users who are moving toward SQL, and ABC doesn't always deliver the performance they want, particularly in larger operations where there's a lot of concurrent users.

[Another] area that we're looking at is support for stored procedures. We want to be able to generate code to call existing stored procedures, whoever may have written them. Now creating the code that maps stored procedure parameters correctly can be fairly time consuming. Every variable has to be correctly mapped for the call to the procedure to work. Not everyone has the expertise to do it correctly. If you can import existing stored procedures and then get Clarion to generate code to call those stored procedures correctly, you save yourself a lot of work. And if you add to that the ability to generate new stored procedures based on the metadata in the dictionary, you can really accomplish something useful. And that's where we're going. The premise that we have is to provide a really simple, extensible interface to get optimal performance.

You've also announced an ASP product. How does this fit in with your web development strategy?

Pure web apps and apps that run over HTTP [on a local machine] are a separate subject. A pure web app to me is one that uses one of the standards for web applications, like ASP, JSP, Perl, and the like. And that's obviously what we're targeting with the ASP project. ASP is the next logical choice for us. It happens that I like JSP a little bit better than I like ASP, but ASP is supported everywhere. And that's really what we want to see happen, to give Clarion developers applications that they can host anywhere they like.

The mixed development is not a high priority any more?

No. The ASP work will lend itself to being able to call into business logic stored in a Clarion EXE or DLL, but that isn't the focus of it. There are things that ASP applications are really good at, and this is what we can deliver to you.

So the app broker is going to be orphaned?

Not at all. I probably should time this with the press release, but I'm sure you know the ClarioNet product? We have an agreement to become the exclusive distributor for it, so we're going to tweak the app broker a bit. It's a much better use for the app broker than the current approach of generating HTML.

So the web development will split off into two product lines, one for ClarioNet and one for ASP and similar code?

We will maintain and make improvements to the Web builder technology - like the HTML web reports we added in 5.5a, and make improvements to the Application Broker itself. A web builder application can be integrated with ASP [or similar code] to deliver business processes from within a Clarion app to a Browser, processes that would be very hard to model and code in VBScript. The Web Builder technology and ClarioNet are very closely linked because they share the same architecture. But, one of the things that I've felt for many years we didn't do a good job of at TopSpeed was take advantage of the code generator and the metadata in the dictionary. I want to change that. The ASP code generation is a small step in that direction. The work being done to accomplish that will lend it self to, say, JSP. It won't be that big of a step. Or we can do PHP or Perl. PHP will probably be a better bet for us [than Perl]. It will differentiate the product. You'll have the ability to go and choose a language based upon your preference or your knowledge of a language, and its unique abilities. Essentially you get the same functionality with all of them.

Would you be able to switch between templates to move an application from one language to another?

That I can't determine yet. Conceptually it seems like you should be able to do it, but until we go down that path a little further it's hard to say with any certainty.

How is the ASP project coming along?

Fantastic. There's so much we can do with the metadata in the dictionary and the AppGen code generator. ASP code can be difficult to write and even more difficult to read and maintain, mostly because it's so tedious. You're back to keeping all that [information] up in your head. All of the things we did for 4GL programming, we can apply the same principles to ASP. We've got many features already completed, common requirements like page level security, data lists, update forms, database i/o error checking and recovery, and a utility library for things like formatting result sets, populating drop lists, search capability, user-sortable tables, that type of thing.

There are two approaches to ASP. What we're doing right now, all of the applications are server-side VBScript. The VBScript will execute an SQL statement, get the result set, and generate the HTML to display the page to the user. The primary advantage of that approach is that a lot of ISPs don't allow the registration of any server-side ActiveX DLLs or ISAPI extension DLLs, the app broker being an example. And even those ISPs that do support customer-provided DLLs often have special charges for installing them, or they require customers to move to a dedicated server plan, which can cost a whole lot more money.

The disadvantage [of using VBScript this way] is that you don't have a separation of presentation and business logic. The second phase of the project that we could deliver would separate that out, by taking the business logic and putting it into a COM object, [similar to the JSP/custom tags approach].

Are you planning any XML support?

Absolutely. The XML solution is going to give you the capability to read and write to IE5 XML data islands, and to ADO persisted XML or to XML files with XML schemas. Essentially what will be different about our approach is that it gives Clarion application the ability to read and write XML using standard ANSI SQL92 statements. That includes support for SELECT, INSERT, ORDER BY, GROUP BY, etc. For our development community, people who have a database slant to their experience, it's going to be especially attractive. Essentially it's just another driver at that point. A user would be able to set up a local data source that contains a URL to an XML file anywhere on the web or on a local resource, and read or write to it.

Which parser will you recommend, or will you supply one?

We're definitely not going to include a parser. The Microsoft XML parser or Xerces are two good choices. If you want to go beyond [the XML driver], we'll provide a wrapper class for probably both those two, but at least the Microsoft parser. We also have someone looking at what it would take to wrap up the Xerces parser.

Any thoughts about adding SOAP capability to Clarion?

Nothing I want to discuss in detail yet. We've looked at SOAP, and there are some aspects that are very attractive. When we looked at how we could do it, we came up with what seems like a fairly easy approach to implement, using our XML driver as a component on the server. Part of the solution is tied in with the XML driver, the other part is a Clarion application on the desktop. The answer is probably [won't be] complete in the next couple of months; it won't come out as an official implementation at the same time as the initial XML support.

Which suggests the XML support will be out in the next couple of months.

Yes, Absolutely.

How about the 32 bit IDE?

A lot of the work to get the environment to 32 bit was done as part of the IBuild project. Most in fact was done.

This was just a straight port, no new functionality?

Yep. Some of the things that weren't ported, like the editor, are easy to replace or even rewrite. Fairly easy, but not trivial. And some things have been around for so long that nobody wanted to touch them initially, like the window formatter and report formatter, both of which could stand a complete rewrite. The areas that aren't in 32 bit yet are areas that we're not sure we want to put into 32 bit as they stand today.

Will there be a 32 bit IDE in C6?

I think the community has pretty well decided that if we release anything with the label C6 that isn't 32 bit, we'll be run out of town. So the answer is there will be a C6, and it will be 32 bit. The 32 bit IDE work does continue. What we've really focused on is rewriting the sections of code that affect robustness and stability. There are more than a few people who are well respected and who work with us who think we ought to be looking at 64 bit. Right now we're hybrid 16/32 bit, both in the environment, which isn't as significant except where it impacts COM support as in the formatters. The fact that we are 16/32 always gave us a nice advantage. What we're looking at now is what if we leapfrog to 32/64.

Is there a pressing need for 64 bit performance, or is it more of a marketing issue?

It's more to keep pace with the direction the industry is going in. There will be performance advantages, but with 1 GHz machines for under, I think, $800, performance is less of an issue.

What's the status of COM support, like the COM interface Jim Kane wrote about recently in ClarionMag?

The COM interface rewrite was part of a project, started well before 5.5, targeted at providing COM syntax almost completely like VB's, and improving the interface to COM objects as well. It's undocumented because it's incomplete. That work hasn't been a priority in the last 3 months...

The dot syntax isn't there yet.

In order to provide [VB COM syntax] and not hybridize the language, we need to move the entire language to full and complete support for dot syntax. When that's done, we'll be where we want to be.

Is dot syntax a C6 feature?

Probably prior. We can incrementally release updates that move in that direction. What we just released in 5.5a were some significant bug fixes. There are many more fixes that are internal, core fixes and enhancements that wouldn't make sense to anybody if we documented those [publicly]. Simultaneously we have new development going on. What we have to decide is do we hold back until everything that we'd like to see in C6 is done, or do we deliver things incrementally. I'm of the opinion that delivering technology incrementally is a better approach to take. The company does better and the developers get their hands on the technology quicker, and everybody's happier in the end.

Do you have any plans for ADO?

We sure do. We started to work on ADO four months ago, or a little longer. Recently Andy Ireland, who worked in the Development Centre, and now works in the U.S., offered us the considerable amount of work that he had done for his own project. We'll be combining the two works, working closely with Andy, and we'll write templates that wrap Andy's classes, and we're going to be adding additional driver support.

Do you expect to have support for native threads in C6?

Yes, if not before. I don't know if we'll hold that back for C6. Three months or so ago I put rewriting the thread support for the 32 bit RTL at the top of the list. That [makes it possible] to get rid of data swapping completely. Even though the documentation says the RTL allocates memory for threaded data instances for every thread, in the current implementation if you use the ADDRESS function on a threaded variable, it's going to be the same [address] on all threads. [The RTL swaps] instances in and out when the thread becomes active. This is one of the reasons for GPFs and memory corruption, and thread synchronization errors. If we exclude swapping, threads can be synchronized very easily. The downside is that the ABC classes use the fact the address of the variable is essentially the same across all threads. It's possible, of course, to change those classes, and the problem then is that changing classes can break programs that depend on those classes.

And there's a whole other area of synchronization and true processes that Clarion developers will need to become familiar with.

That's true. I think the initial implementation was very clever, but it was shortsighted. Eventually it came back to haunt us. The positives if we make the changes is that you'll get much more robust code. And faster execution, pre-emptive task switching, a whole slew of benefits. The only downside is the potential for breaking existing programs.

You mentioned JSP earlier. Any other plans for Java?

We actually have a research project going to do client side or desktop Java. It seems quite reasonable to take advantage of Clarion's core strengths with the use of metadata and code generation. We're looking at the current JDK to see what we'd need to accomplish to deliver a Java client program. I think it's just a natural. I tried to convince Bruce [Barrington] to do this when the first JDK was out maybe two, three months. I wrote a couple of programs, I said "Hey, Bruce, look at this, this is going to be hot stuff! People are foaming at the mouth over [Java], and we can turn them into Java programmers overnight." And I was shot down on that one. It was bytecode. "That's pseudocode! That's where we came from! We're not going back there..."[laughter] Of course we'd paid a heavy price to move from pseudocode, so I could see where he was coming from.

Client side Java does seem to be making a bit of a comeback.

I think it is. As the performance of CPUs continues to go up the performance of Java becomes less of an issue. For well over a year I've been reading that Java is pretty much equivalent to C++ in many benchmarks. For us, Java will get us into places that we can't get into otherwise. In a lot of companies, if you don't say Java, they don't even want to talk to you.

How do you deal with some of the language differences, such as how Java lays out controls on a window using layout managers as opposed to fixed positioning?

The people we've had look at this, and we've actually had some people who have been users who have now been programming in Java for some pretty well-known corporations, and I brought up that exact issue to them. And we were actually approached by two separate corporations who said "Look, we really like Clarion, but we need Java, and we'd like to help you get there." Code generation is something we're great at, and I brought up the exact point that you brought up. There are really only two ways to handle it. One is to say okay, you lay it out and we make a best guess of what you intended. And that isn't entirely bad for Java, but you still don't get to see what you would have done until you actually run the program, which maybe isn't ideal. The second thing, which we could do, is to provide a plug-in, and the plug-in would be a Java module that would render up the UI and show it to you. The final step would be to render it up into a formatter and let developers adjust the design and save it back, and now you have a complete formatter.

I've heard from people who say don't even worry about that, [who have] given up on positioning in Java, literally. And these are guys from shops that are pure Java. So maybe it won't be an issue. In my own mind, I'd rather see us say "That's fine, but we're going to at least let you see what it looks like." And depending on the difficulty, and what the time line and the costs would be, maybe decide we can do a little bit better than that. We can at least let you render it and change layout schemes and layout managers and fool around a bit with color and sizes. Time will tell how far we go down that path.

Do you foresee an alpha available any time soon?

It's still in the research stage.

Is Java where you'd be looking for your cross-platform capability? A lot of developers have been asking about a Linux version of Clarion.

We're not currently looking at a Linux version of Clarion, but as Linux evolves on the desktop that may be something that becomes more important to us. From my experience, Linux is strongest on the server side, particularly on our continent. Even [in Europe] I think it's real strength is on the server side. To port the development tool over, at this time I can't say there's a push to do that. Now to run a Clarion application on a Linux box, we could accomplish that with the ability to create a Java client, or a C++ program.

How about C#?

We've been looking closely at the whole .NET framework. There's a lot of overlap between a requirement to generate Java and a requirement to generate C#.

The specifications for those languages are very close. It seems that a developer could move from one to the other quite easily.

No question there is a great deal of common ground. The same principle holds as for JSP/ASP. Right now Java obviously has the mind share for developers and corporations. C# is increasing, but I've looked at some surveys that say a lot of developers aren't interested in C#, and surprisingly so. People who built their careers on C++ aren't jumping on the bandwagon, people who do Java definitely are not interested.

Any plans for Windows CE or other handheld devices?

The first interview we did I talked about the untapped possibilities of our code generator, and I think that applies to Windows CE and to handheld computing in general. There isn't an immediate link between a Clarion application as we traditionally know it, and a handheld device. There is an inherent capability of the product to say we can automate a large portion of the requirements for a Win CE app. Do we have anything that we're doing today? No. We looked at it, [asked] what would it bring to us as a company. Right now it doesn't have the appeal of other things we can do, but it could become a part of the future using the basis of other work we are focused on.

How do you best apply your resources to stay competitive in the development tool marketplace?

In a lot of ways I think we're more able to respond to the market than Topspeed was. At any one time now we'll have anywhere from two to five research projects running, with one to four developers just looking at what it would take to integrate, add on, or extend Clarion. Most of these developers have been contracted with because they have expertise in the technology that we're interested in. We then get the ability to access the very best people who have expertise in something that we're interested in, without having to train people internally and the ramp-up time associated with that just to investigate feasibility. There isn't anything that's impossible to do if somebody with talent and experience puts their mind to it. What we need to do is identify what areas we want to go in. In the past the development staff was pretty good sized, we had a team of guys that worked on the same technology in the same office, and shared the same vision of where they all should go. What we've been able to do is find people who aren't connected to the Clarion community at all, and say [to them] "Look, we're interested in this particular technology, and this is what we want you to do." We take the results and we decide if it's something feasible for us. For instance, that's what we're doing with the Java client side project.

You're really branching out into other languages in a big way.

Absolutely. What's really becoming clear is that Clarion can easily evolve into a language-independent product. Yes, we have a core language, and yes we have incredible capabilities in the language and a fantastic compiler and linker , but if you want to use Clarion the development tool you won't be restricted to just the Clarion language.

How about the CBT courses? Anything new?

Yes. One of the courses that we're going to do is in conjunction with the SQL project. The reason being that through firsthand experience we find that a lot of people want to move to SQL and they need two things. They need to learn a little bit about the differences between ISAM file processing and SQL processing. And two, they need to learn the specific implementation of Clarion and how to best optimize it. So that is one that we're going to do. We'll do a course covering the XML support, without question. We may or may not do one with ASP, and the reason is just that there's so much information about ASP out there that it might not be that useful. On the other hand we end up saying okay, here's either a little mini course you can download or something that comes as a CD and just shows you what we can do, and if you really want to learn ASP, just go and pick one of the four dozen books on the market and I don't know how many videos and CBTs that deal just with ASP.

So you're shifting your focus to CBT and away from classroom training?

Not really, we still see great value in classroom training. What we found is that unless we really start reaching out across the country a lot of people either cannot get the time off, or can't afford the cost of travel plus hotel plus the course. So rather than hold them back, the idea of letting them take the course either online or via CD is pretty attractive. As far as the instructor-led training, we're routinely running classes. We try to run at least two every month, and we are looking at doing classes outside of Florida.

Will there be a DevCon 2001?

The answer is yes, but we haven't decided exactly when and where. I won't do anything along the lines of the Pier 66 conference, and mostly because of the cost. I thought it was overpriced for many developers who wanted to attend. I want to do it so it's more affordable to developers, and so that it actually can generate some revenue for the company. And the other thing I will do, without question, is put 98% of the focus on technology and technology transfer, and 2% on marketing. We could make a dot release, and say 'attend the conference, get a dot release, and here's what you'll learn'. Make the whole thing essentially training courses. Including of course presentations and demonstrations of technology that won't be ready to ship.

What are you interests and hobbies outside of Clarion?

Is there anything outside of Clarion? I'm kidding. With two kids, a lot of my hobbies have changed dramatically. No more sky diving, no more hang gliding, a lot of the things I enjoyed have been vetoed. I used to be an avid sky diver, and when I could get to somewhere that wasn't flat I liked to do some hang gliding, which you can't do much of down here. I did some ultralight flying, and that was pretty enjoyable. I used to like a lot of the air sports. Kelly vetoed all that. But I said when the kids get older, though, I'm going back to it[laughter].

Clarion Magazine Readers Respond

Following the publication of this article we asked Clarion Magazine readers to respond. Here are the results of the poll as of March 21, 2001:

The response numbers were as follows: