Visual
FoxPro DevCon 2005 Interview with Alan Griver and Ken Levy
FoxTalk
editor David Stevenson interviewed Microsoft’s Ken Levy (VS Data Product
Manager) and Alan Griver (VS Data Group Manager) about the Visual FoxPro
Roadmap and upcoming project for enhancing VFP code named Sedna. The interview
took place on June 14, 2005 at the VFP Advisor DevCon conference in
Interview: June 14, 2005
Published: August 2, 2005
David Stevenson: VFP9 is on the scene now and seems to be getting a
great response from VFP developers who have tried it so far. What are you
hearing from the community so far?
Alan Griver: We’re hearing pretty much the same thing. About a third of the
community has upgraded so far, which is very much in line with expectations.
People are saying it’s the most stable version of VFP. People are thrilled –
you know you talk to any four or five people and you get four or five different
responses on their top feature, whether it’s the reporting enhancements, the
new data types, the SQL enhancements, etc. So, I think we hit a home run with
this. I didn’t think we could beat 8, but we actually did.
Ken Levy: The
other thing is that people haven’t quite tapped into the full extensibility
model. At the same time, you have things like GDI+ and other features that we
included that aren’t necessarily highlighted. I think there is a lot to be
discovered over the next 6 to 12 months from samples, articles, and so forth,
that will surface quite a bit more functionality in VFP9 that people haven’t
read about or don’t even know exists. The BindEvent [enhancements] are probably
still an untapped area of power. There are a lot of things that we can do with
9 that we haven’t done yet.
David Stevenson: There were some comments made the
other night at the meeting about there being surprise from the time you started
working on VFP9 until you finally got feature-complete. I know the community
was surprised, but you indicated that some of the Microsoft people were
surprised too. How do you think that will play into the new plans for Sedna?
You have some parameters laid out right now for what you think Sedna will
include, but it looks like two years is a long time, and people could come up
with a lot of cool things.
Alan Griver: Well, if you think about it, VFP9 took about two years also, so that’s
about on the basic schedule. What happens is that you go ahead and set a number
of core pillars for a release, and then you do some executive reviews where you
say, “Here are types of things we are looking at.” They tend to be kind of
architectural concepts, and the way you know that you’ve nailed them right is
because as you’re developing, it suddenly leads to a bunch of new things that
can be done down the road.
I used to see that all the
time when I was developing using Fox and using VB6. Here it’s the same case. We
went ahead and said, “Well, we know we want to enhance the report writer,” for
instance. Here’s an idea architecturally for how we want to do it, and all of a
sudden, multiple detail bands fell out of it, and multi-pass reporting fell out
of it, and all of these other things came just because we had architecturally
designed it properly.
That’s what we believe will
happen also with Sedna. We’re setting some core architectural approaches, and
we’re saying that we’ve engineered the product for extensibility. I think
Ken Levy: I
think with all these new technologies coming, and the extensibility that gives
us the ability to glue these things together, I have a pretty good belief that
we can come up with some stuff that will be pretty exciting. Just here in the
keynote, I was excited about some of the demos and I could feel it in the
reaction of people. Like, the potential – where are they going to be two to
five years from now. So, we’re just scratching the surface and there’s a lot of
potential – such as FoxPro’s extensibility and data-driven aspects of
programming.
David Stevenson: One thing that people are wrestling
with now is how to interpret the new style of update that Sedna seems to
represent. You described it in the keynote as being like an SP2 plus some
add-ons, saying that it’s more than just a service pack. But, if that’s the
case, why isn’t it being called 9.1 or 9.5 or even VFP 10?
Alan Griver: First of all, we haven’t given it a name yet. Right now it’s called Sedna, but we haven’t
said whether it will be a 9.1 or 9.5 or whatever.
David Stevenson: Right, but you described it as a
service pack plus add-ons.
Alan Griver: If you think of, for instance, Windows XP SP2, that added a lot of
functionality to Windows as well, similar to how Sedna will do that for Fox.
We’re finding that we may not have to heavily touch the core bits – that
additional DLLs, just like any application you write might have one core EXE
but a bunch of different DLLs, additional Fox extensibility can give us a wide
range of features. And it keeps us on a really stable base, so that also helps
with people migrating, and et cetera. If it worked on VFP9, it will continue to
work because it’s the same code. So, you get the enhancements and you get the
stability.
Ken Levy: One
of the things we did after we shipped version 9 is we stepped back and said
rather than following a traditional path, we looked long-term. I don’t mean a
year from now, I’m talking three to ten years. What’s
our path. Where do Fox developers need to be, what
kind of things will they demand, what will their users
demand. With our team’s limited resources, just like with 9.0, we had to be
very meticulous in what we prioritized. We can’t just do everything. If we were
to spend a whole lot of time, for instance, on the grid control, it could take
a huge amount of time in planning, development and testing. It’s not that easy
to just crack open something and make changes.
If we took all of that
effort and put it into something that had to do with Longhorn (Windows Vista),
for example, it might benefit users and their applications far more. So it’s
like the quote from Spock in Star Trek, “The needs of the many outweigh the
needs of the few, or the one.” That’s something that we think about on occasion
when we’re thinking about these features. We have to sit back and try to decide
what are all of our options, and let’s think out of
the box. What are the options of what is it, how do we package it, how do we
distribute it. We’re keeping all of our options open and we’re thinking that
having regular betas that will allow people to see what we’re doing and know
way in advance exactly what we’re thinking. So, it’s not this big surprise in
six months – what did they announce. And it’s like this big letter with all the
new features and hardly anyone knew what was coming, and then they wait six
months until the product releases – that type of thing. Here [with Sedna] on a
monthly basis they see the evolution of it and have input and the community
becomes more an extension of the FoxPro team itself.
Alan Griver: This is something that we’ve seen be very successful with Visual
Studio, with the feedback center and also the CTPs, the Community Technology
Previews. Visual Studio has been providing a release that says it may not be up
to beta quality, but you can see everything that we’re doing on a
month-by-month basis. Now SQL Server has taken that on, and now Fox is looking
at doing it as well. It’s something that I think you’ll see more groups do.
Ken Levy: This
is not a marketing plug, but it’s a true technical tip for software developers.
Look into getting a very inexpensive program called Virtual PC. It’s a great
way of running beta software and experimenting with things, so you can keep up
to date, put a little time in there and give us some feedback. I think that
will go a long way in our efforts in building Sedna.
Alan Griver: I do want to make one thing pretty clear for people who are worried
about how to keep up with these monthly releases – something that the Visual
Studio community went through – and the answer is that you don’t have to pick
them up every month. When you find you have some extra time, you go and
download the latest version, play with it, run your current app on it and
report bugs.
David Stevenson: Do you plan to be releasing that
often – monthly?
Alan Griver: That’s one of the things we’re looking at. With the size of the team,
it may not be quite as often, but we’ll see. We’d like to be a lot more
transparent and a lot more open about what we’re doing, because we’re part of
the community and the community is part of the team, and we’re always leading
the way, or closely following in this case, in how we can bring the community
closer into the product. We’ve always taken enhancement lists – we led the way
there – and here we’d like to see if we can do something more than one public
beta, which is what we’ve been doing.
Ken Levy: The
two most common questions are, “What are you doing with FoxPro?” and “What are
you not doing with FoxPro?”. People really want to be
able to make decisions and plan things out based on good information. We want
to increase that dramatically on a more rapid basis.
David Stevenson: Well, on that note, I have noted in
some of the discussion online that people are trying to understand what the
(VFP) Roadmap really says. There is a set of words there and there’s an FAQ
entry that points right back – they point to each other. The one comment I’ve
seen people react to the most is that the Roadmap contains “all of our plans”
for enhancing Visual FoxPro.
Ken Levy: All
of our current plans.
Alan Griver: All of our current plans.
David Stevenson: Does it actually say “all of our
current plans”?
Ken Levy: On
the FAQ page it says all of our current plans for enhancing Visual FoxPro are
located in the Roadmap. That’s subject to change at any time.
David Stevenson: The obvious follow-up question is,
“What are the chances that there will be further enhancements beyond Sedna?”
Alan Griver: It’s something we’ll look at towards the end of Sedna, just like we
looked at Sedna toward the end of VFP 9, we looked at
9 toward the end of VFP 8, and 7 toward the end of 6. With the team that we
have we basically can look one version up. Right now, Sedna is actually
probably one of the bigger bets and efforts that we’ve taken in a while. If you
think about it, the last time we’ve had an architectural shift in the
underlying environment was when we moved from DOS to Windows,
or maybe from 16 to 32 bits.
What we’ve got now is
essentially a new platform on Windows and we need to play well on that
platform. We know that it’s coming over the next couple of years and Sedna is
the release where we have to start taking that into account. So, all of our
efforts are involved in that. Just as a simple, simple example, Longhorn
(Windows Vista) has how many new APIs, Ken?
Ken Levy: Over
3,500 as it stands now.
Alan Griver: So, that means we have to look at all of those and figure out which
ones do we want to make really drop-dead easy to work with in Fox, how do we
want to extend it, and that’s just … work! So, right now we’re focused on Sedna
and we’re not focused on anything beyond it. We can’t say anything about
anything beyond it, but that’s no different than it has been every release.
David Stevenson: I think the thing that would most
concern people is whether the door is actually closed to further enhancements.
Ken Levy: A
big direct answer the best we can on that question is that there is a
possibility that there won’t be any enhancements after Sedna, and there is a
possibility that there will be. We would have answered the question the same
way after we shipped 8 and people asked about what’s beyond 9. We’re being
totally honest and we’re just not dancing around it in any way. There is no one
at Microsoft who has had meetings or decisions, and we’re waiting for two more
years to plan that out.
Alan Griver: The short answer is that the door is not closed to there being
enhancements beyond Sedna. The other side of that is that we don’t know what’s
behind the door yet.
Ken Levy: Our
two objectives around a lot of things in Sedna are, we
obviously would like Visual FoxPro developers and their users to use more .NET
technologies when it’s possible, and to eventually upgrade to Longhorn (Windows
Vista). That’s kind of an obvious thing. The other side of it is, as FoxPro
developers and solutions do leverage .NET and have needs in that space, and as
they do upgrade to Longhorn (Windows Vista), we need to make sure they succeed
as much as possible and that they don’t have any roadblocks. So, it’s a mixed
thing. We’re trying to encourage people to use other products and technologies
to make better applications, and at the same time help them along the way and
not let them be left behind.
David Stevenson: How did you arrive at the idea of this
type of packaging of enhancements? This is clearly different from what we’ve
seen in the normal product development in the past.
Ken Levy: To
be directly honest, it was in discussion with upper management, including Eric
Rudder. It was a collaboration of ideas and options where we all hashed out
what were all the things that we could do, and it seems that everybody agreed
that this was the best option for the long-term result. We’ve stated clearly
that our goal is not to add FoxPro directly on the .NET platform, but we’re
going to enhance FoxPro as an evolutionary base, and then add more Visual
FoxPro-like features into Visual Studio (.NET). We have to keep both those
things in mind.
Alan Griver: I have a slightly different answer. It all depends on what makes up a
release. We can ship a product – and I think this is changing in multiple
places – here’s an example. If you look at the Linux world or if you look at
the open source world, you’ve got all these different releases going out at the
same time, and you pick one from column A, two from
column B, and et cetera, and it’s really confusing and hard for people to keep
up with.
What we’re saying is that
we have a pillar for Sedna. That pillar is interoperability. The minute you say
that, it means you’re not going to be changing the grid control. You’re not
going to be touching textboxes. We’re not going to be doing more to the SQL
engine – we did a ton in VFP 9. We can do things one of two ways. We can say,
it’s all going into the EXE, which will now grow by X hundreds of bytes or megs, and you have the possibility of introducing new
instability into the code that existed.
Or, you can say, you know
what, architecturally, we did a great job with 9, and what we’d rather do is
create satellite DLLs that don’t affect the core stability of the product,
which we know is unbelievably strong. Let’s just go ahead and see how far we
can get in adding these features without touching the core. Does that mean we
won’t touch it. No, that’s why we said an SP-type of thing.
There may be some things where it will work architecturally a lot better with a
different type of hook in there, so let’s add the hook into the core product
and make it available to the entire Fox community, and we’ll use it, too.
People always talk about
programming languages being written in themselves. The
.NET framework was written in C# and in VB. More and more parts of Visual
Studio are now written in the managed (.NET) languages. It’s the same reason
that anything that we add for ourselves benefits our customers. This means that
if we add new extensibility capabilities in Sedna and we prove how much can be
done – you know, if we can do half the things we defined in Sedna without
touching the core product, you know what, Fox is a hell of a product.
So, I think that’s really
the core, and by not touching the EXE, it also makes things a lot easier and,
frankly, it cuts down on some of our expenses, too. It means that our testing
doesn’t have to be enhanced as much, and we can run the VFP 9 tests and assure
that everything continues to work. It means training and support costs. It
means that all the case studies – we’re about to have five new case studies up
about VFP 9 on the web – it means that those case studies stay current. The
moment you release a new version based on a new EXE, all of those case studies
go into archive and you start over again. It just gives the people who have
worked with us on the case studies more time for the advertising potential for
those case studies. So, I think it’s actually a big win for a lot of people.
Ken Levy: I’ll
follow up on two things that YAG said. On a technical front, we may be doing a
lot of things as additional DLLs written in C++, the same way you’d code a
component native to core VFP. For instance, we might expose a lot of APIs for
Longhorn (Windows Vista) and try to treat it like natural language extensions.
We could easily put those into some kind of DLL and say SET LIBRARY TO and once
that one line of code was executed, you would have an extended language. And we
have all these other components that do all these other things,
and you’re building on the VFP 9.0 platform, so to speak. One other benefit of
that is that when Sedna comes out, there may be a whole lot of things across
the board in Sedna, and there may be some people who only need 30 to 70% of
that capability, and they get to pick and choose which components they use
mostly without even touching the existing application because it’s already on
the same base. The upgrade process and the flexibility in testing should be
even better for them. It makes the management of the solutions and the
deployment a lot better.
Alan Griver: The other thing is that this isn’t anything that we haven’t done
before. I go back really far, right?
David Stevenson: Really far!
Alan Griver: Really, really, way too far. For those of you who don’t know me, my first version of Fox was FoxBase 1.21. One thing that
a lot of people may not remember is that when you first wanted to access SQL
Server from Fox, you got the connectivity kit, where you essentially did a SET
LIBRARY TO and suddenly you had access to SQL Server. It didn’t actually make
it into the product for two or three releases, so at first, that’s what you
used. You had COMUTIL (VFPCOM.DLL), and in order to get access to a lot of the
COM events, you actually used a library – a separate file. We’re going to
continue in that proud tradition.
Ken Levy: And
when we need to update these components with evolving technologies, we can
update just these little components and not the entire product. Rather than
like, service pack 1, 2, 3 and 4, just with core features that relate to
external technologies, now we can have components that you just plug into,
whether they’re FFC components, DLLs, .NET wrappers, and so forth.
David Stevenson: There has been some talk about how
you’ll have the betas progressively over the next couple of years and let
people see what’s being worked on, but the final release of Sedna, however it’s
packaged, will probably be something that people will pay for.
Ken Levy: The
way we generally work on packaging, is that I’d say around six to eight months
out from the release we start working on the packaging, the distribution, pricing
and a name. It all comes together at about the same time. In the case of Sedna,
it will be about the end of 2006. The other thing is,
that we need about another year and a half just to figure out what Sedna is. We
will be deciding things early, but it will continue to evolve, and it could be
April of next year that we have an epiphany and come up with something we
hadn’t even thought of.
Alan Griver: One other thing about the pricing and the beta – it’s not different. I
think in some cases, people are freaking out because we have a Roadmap where
we’re saying these things. VFP 8 had a public beta that was free to everyone,
but once the product shipped, if you wanted to keep using 8, you paid for it.
VFP 9, public beta, free to everyone. Once it shipped, you paid for it. All
we’re saying here is Sedna, public beta. What’s going to happen when it ships. We’ll find out, but you know what, yes, there will
probably be a way for us to gain revenue from it.
David Stevenson: There has been a public statement, I
believe by Ken, in response to someone’s question, that decisions about VFP’s
future are not tied to the sales of VFP. What are those decisions about VFP’s
future based on?
Ken Levy: To
be clear about that, if for some reason the graph of the sales changes in some
way, it’s not like we’re going to stop and say, I guess we’re not going to do
Sedna. We don’t want people to feel insecure about our plans and commitments
around the Visual FoxPro Roadmap as they relate to VFP 9. There may be some
people who wait a few months to upgrade – maybe building on VFP 8 or VFP 6, or
whatever, and we’re very committed to help FoxPro developers and the users of
those applications move forward on new Microsoft products and technologies. So,
this is a very strategic release of additional FoxPro functionality.
Alan Griver: We’re always looking at revenue, right? But once we’ve got the budget
for a new version, revenue becomes less of an issue. Before we had the budget
for Sedna, before we had the commitment for Sedna, part of the issue was,
indeed, are we making money off of this thing. Could we better utilize some
resources elsewhere? You know, that same discussion happens about every product
every time. Can we get enough people to upgrade to be worth the massive effort
to do the next version of X?
David Stevenson: That brings up the question of the
VFP team. I think a lot of people are very interested to know what is happening
inside the VFP team. We know that some of them are working on things for other
projects with part of their time. How does the team look and how will it look
over the next several years in terms of size, and what percentage of their time
is going to be devoted to Fox?
Alan Griver: I made a blog entry a few months ago – not in much detail – that basically
talked about Visual Studio Data, which is the team that reports to me. It’s a
team that is made up of multiple groups, if you will. Fox is one of them, and
the Data Tools in Visual Studio is another. I don’t believe that there should
be a wall between the two teams. To that end, some of the Fox people are
bringing some of the great capabilities of Fox to .NET. But at the same time,
there are people from the Visual Data Tools team who are working now on Fox.
It’s not a question of resources going only one way from Fox to Visual Studio.
I’ve taken a program
manager named Milind Lele, and hopefully, when we get back, we’re going to
start introducing some of these people to places like the Universal Thread.
Milind is now working with
For me, that’s really
important that there not be any kind of boundary between the two. To that end,
also, if you look at my management group, some of my managers, such as my test
manager, a guy named
Ken Levy: People
need to remember that we’re still part of one team, and that’s the Microsoft
team.
David Stevenson: That sounds like a typical marketing
answer.
Ken Levy: An
example is that our team helped drive and sponsor the XML tools that went into
Visual Studio 2005. That was a small part-time effort during the development of
Visual FoxPro 9. But there’s a lot of other work with the documentation and all
these other factors that is across multiple teams. So, yes, there is a core
team that works most of the time on Visual FoxPro, but there is a bigger aspect
to the whole development and shipping of FoxPro and other things that relate to
it. That’s why I say it’s one big Microsoft team –
it’s not completely isolated groups.
David Stevenson: You mentioned SP1 for VFP 9, due
somewhere around the end of this year. What should we expect to see addressed
in that service pack?
Alan Griver: That’s going to be a more common type of service pack that you’ve seen
which will just address any critical bugs that we’ve seen.
Ken Levy: It
will be more like SP1 for Foxpro 8 – there will just be one for version 9.
Alan Griver: The reason for waiting we think until the end of the year is because we
just haven’t had enough critical bugs reported to us yet to make the rollup
worthwhile. It’s kind of an interesting balancing act. A service pack requires
a lot of testing, right? We have to test it on multiple operating systems,
installed with multiple other applications. We have to make sure SP1 won’t
break Excel or Visual Basic or whatever. There is a big matrix of testing that
goes into it. If you ship it too early and then you start getting feedback on
other critical bugs, you then have to do a second service pack and that will
blow out my test resources, which will affect Sedna. So, we like to make sure
that we’re on a downward slope and that we’ve got a good batch of critical
issues to address. The number we’ve gotten compared to 8 is so much lower that
we’re waiting to make sure we hit it right.
David Stevenson: There has been some talk of your
wanting some input from the community on what they would like to see included
in Sedna. Someone made a comment in the keynote to “give us some scenarios and
we’ll go after the technical side of it.” What do you really need from people
and what’s the best way for them to express that to you?
Ken Levy: Right
now, what we’re putting online for the community is a lot more in-depth
thoughts and ideas and parameters around what we plan to do with enhancing
Visual FoxPro than we have done with any previous versions. So, on a regular
basis we’re disclosing what are our boundaries, what are our overall
objectives, almost like buckets or areas that we’re going to prioritize on.
Over the next few months, we’ll drill into each one of those to determine more
specific features – what’s the impact, what’s the scenario that drives it. We
have to justify each thing we do and how it compares to something else in
impact.
We want to have the
community follow along with us with almost monthly releases of information
about what we’ve planned – new ideas – and then give us feedback on each. It
doesn’t mean that there will be random ideas that have no context to our goals
and objectives – we want the community to follow along and see, OK, this is
what we’re trying to do, and interact. Just like the whole grid thing, if
someone wanted a new column type feature for the grid, we probably would say
that’s not on our priority list – can you give us some features and scenarios
around the goals that we’ve outlined?
We want a lot more
interaction with the things that we release on a regular basis, just like in
the Sedna section of the VFP Forum on the Universal Thread.
David Stevenson: How should people do that? Should
they send an email to you or to Randy, or post something on the Universal
Thread or the wiki?
Ken Levy: Direct
email is hard because there is no way for it to be easily discussed with
multiple people. Right now, for a little while, go into that Sedna section on
the Universal Thread, but we are researching other avenues online to have
input, discussion and feedback. We’re going to evaluate a feedback center later
this year.
Alan Griver: To make it really clear to people – we have published the pillars for
Sedna. They are .NET interoperability, Longhorn (Windows Vista)
interoperability, SQL Server 2005 interoperability, and Office 12
interoperability. So, the best thing that people can do is give us some
scenarios. How do you plan on using it? You might say, I have a major VFP app
I’ve been working on for years, my company just merged with another one that
has a .NET app, and we need to get the two to communicate. Here are the issues
that we’re finding based on VFP 9 – it would be so much easier if there was a
way to automatically do this. Or, I hear that Office 12 is storing all this
data in XML format – wouldn’t it be wonderful if we now had a new export type
called Word 12 or Excel 12? It’s things of that nature
– kind of the high-level scenarios for things that will really help people if
we make it available.
Ken Levy: One
of the really important pillars to add to all of that is the area of
extensibility in FoxPro – what we call internally the “Xbase components” that
are written in FoxPro. In the keynote, two of the exciting demos were of a new
extensible “My-dot” architecture based on Visual Basic 2005, which is like
speed-dialing into common or uncommon functions to discover things. The other
one is the report functionality that was demoed, that basically extends the VFP
9 report system, where you hook in and declare things easily with no code, and
then report listeners get turned on and executed automatically. All of that is
written in Visual FoxPro, and we believe that there are many, many aspects of
enhancing core VFP that relate to no other external things, that we can package
up in Sedna. So, it’s kind of like the best of both worlds: interoperability
and great new features in FoxPro.
Alan Griver: But I do want people to be clear. When we say scenarios, we want to
understand what they’re trying to accomplish. We may accomplish it using Xbase,
or a DLL, or cracking open the bits and making careful changes to the
executable. We’ll figure that out, but if we have a lot of good scenarios and
we do our job right architecturally, we may find that half of the scenarios get
solved by doing on architectural change in Fox – that’s really what our job is.
David Stevenson: YAG, you mentioned earlier that it’s
important to get this feedback early in the design process while there is still
time to potentially affect the other technologies, and you mentioned that there
are things in Visual Studio 2005 that were changed due to some problem relating
to Fox. Can you be more specific about that?
Alan Griver: One of the nice aspects of owning VS Data and being responsible for
the data story for both Fox and VS, is that we could
do certain things like making the Server Explorer and much – I can’t say all –
of the data access itself in Visual Studio 2005 data-driven. The data happens
to be XML files, but it means that, for instance, if you add a SQL Server 2005
database to Server Explorer, you create a connection to it, you now see more
things than just Procs and Tables and Diagrams, which is what you had before.
You now get things like User-Defined Types, Assemblies, and et cetera. We added
that feature through the extensibilities that we created.
That means, for example,
that we can partner with IBM or Oracle, and when you click in Server Explorer,
you see not just Procs and Tables, but with Oracle you see packages. We allow
IBM or Oracle to define for themselves what kind of
views they want to make available to developers, that are appropriate to their
backend.
We can also take that same
mechanism when Visual Studio 2005 ships and provide that type of capability for
FoxPro DBCs, and also we use a lot of the information in there to enable things
like drag and drop form creation, and so forth. Anyone who has tried to create
an Adapter against a VFP DBC in Visual Studio 2002 or 2003 knows that it
requires a lot of hand-coding because a lot of the wizards wouldn’t work. We
have started to take care of a lot of that – I can’t say we’re 100% there,
because we do have to ship Visual Studio 2005 as well – but we’re committed to
using that type of extensibility across the entire data area in 2005 and in the
one after that, Orcas.
You will see that Fox DBCs
just interoperate better in Visual Studio 2005 because of things like this. As I
said before, when I took over the team, we didn’t want it to be just OK, now
we’re going to support Fox in Visual Studio. No, we said what can we
architecturally do that will allow us to solve this problem of supporting N
databases, and that’s what we did. Part of the Fox background that so many of
us have, is that we think more at that level in terms of data-driven
capabilities.
David Stevenson: Should we expect to see more
data-driven capabilities in future versions of Visual Studio?
Alan Griver: I would expect to see a lot of things that you’re used to from Fox
make it into Visual Studio over time. Another example, for instance, is when I
talk about drag and drop form creation. There is a data source window where you
specify what portion of the database you’re going against to work with in your
WinForm application. For each of those things, you can specify what control
should be used when you drag and drop onto a form, including custom controls,
very much like Fox. You drag and drop and it all just works, and you can use
the exact same data source to create your reports, very much like Fox. So a lot
of those ideas are available – Fox is sitting on the computers of a lot of the
Program Managers who are responsible for data.
David Stevenson: The Sedna blog
that was shown in the keynote – will that be a primary communications vehicle
for the team?
Ken Levy: No,
that was just a fun prototype demo. It’s more like a demo test blog, and what
we’ll focus on are the team member blogs that exist today and the monthly
online letter as the vehicle for getting more formal things out. We probably
won’t use a blog called the Sedna blog, but will leave it like it is today –
the team member blogs and the FoxPro home page.
David Stevenson: You made one comment earlier that I
want to follow up on. You said, obviously we would like to see people start
using Visual Studio .NET more. Why?
Alan Griver: Because it is the core of all the future platform work at Microsoft. It’s
the same reason that where companies had a large investment in DOS, we said
we’d really like to see people using Windows more. .NET is the underlying
platform for everything we’re doing over the next 10+ years.
David Stevenson: So, customers who have an existing
resource and investment in years and years of well-debugged code, that they’re
dependent on for mission critical applications – you’re saying to them,
eventually you’re going to need to re-write that.
Alan Griver: No, we’re saying it will continue to work, just like in Windows today
you can still run VisiCalc from the CPM days, all the way to DOS apps, all the
way to Windows 16-bit apps – they all run on Windows today and they’ll run on
Longhorn (Windows Vista). We’re saying we’ve got a set of well-debugged code
that we are continuing to enhance with .NET – we’re doing the same thing we’re
recommending to people. We have this great code base, and now let’s enhance it
using .NET – that’s what Sedna is.
Ken Levy: Especially
with Sedna, we plan to add a lot of functionality and capabilities, in some
places leveraging the .NET framework, which will require some time spent in the
Visual Studio development environment, to build an application with
functionality well beyond what FoxPro can do alone today. So we believe there
will be a lot more capabilities for Fox developers to use these tools – like a
little more than half the Fox developers use SQL Server with FoxPro. We project
that over half of the Fox developers will use .NET programming along with Fox
programming, as complementary tools in the overall package.
Alan Griver: This is nothing that we haven’t been through before. I remember going
from Fox DOS to Windows, and I remember the screams when VFP first shipped. A
lot of developers have been using VFP for the past 10 years – they may not
remember that there was a huge group of people who said I’m not moving to
Visual FoxPro because Fox DOS and Fox Windows 2.6 does everything I need.
Eventually, people saw the capabilities, and I think the same will happen here.
Ken Levy: To
summarize, the Visual FoxPro team is just as enthused, if not more, about the
potential for Sedna as when we started on Europa (Visual FoxPro 9).