Thats amazing,

- is it possible to host the VFP code into an ASP.Net application?
- is it possible to to use macro substitution-eval ?
- is the data speed comparable with that of "reak" fox?
- can we use vfp table-cursors as datasources of .net control from inside .net ?

Well done!



>Hi Thomas:
>
>
>Some answers below:
>
>As you work for the developing company, a few hints from a very interested potential customer:
>
>?? your example code links don't work for me (W2K, Firefox >> 404...)
>Answer: Links trouble solved, it had to do with the mime type for prg.
>
>?? Are you planning to support vfp functions as well (your site literally speaks only about "command coberage")
>Answer: Try the online compiler you'll see a lot of VFP Functions already implemented.
>
>?? please publish a list of vfp commands/functions already supported/partially supported/planned/not planned
>Answer: You are completely right. The docs will be coming.
>
>?? make a similar separate list for SQL compatibility with vfp (especially when using the exabyte layer <bg>)
>Answer: Well, for this we want full compatibility with VFP, so there should not be differences.
>
>
>?? how about ball park figures for intended price range, licensing model and release targets with disclaimer ?
>Answer: Still planning this, will let you know later.
>
>
>- get more technical in your desription, as I don't have a clear picture of the intended architecture<g>
>
>??? are table layers similar to the replacable drivers for clipper, and vfp runtime is just a layer?
>Answer: Yes but with an OOP twist. Basically there is a class objWorkArea wich provides you the functionality for table representation (EOF(), SKIP, REPLACE, getField, FIELDS(), FCOUNT(), and so). If you want you own layer just derive from this class and implement the methods.
>The current runtime shows how this is implemented for VFP the exabyte layer just extends this class.
>
>?? if so, how can you run on the compact framework ? Are the runtimes needed there as well?
>Answer: In the Compact Framework you could use the Exabyte Layer wich is VFP Compatible until the moment you break the limits, but I guess you won't be shattering limit in the limited environment of the .NET CF.
>
>??? Do you have to implement (and test) your own SQL parser/engine for the exabyte layer
> - Or can you somehow call back from the well tested and to us familiar vfp engine (sys 3054..)
> - Or are you re-Using another already proven ISAM handler (Codebase, Apollo and so on)
>
>Amswer: we are using other engine for the exabyte layer but this does not seem an issue for the SQL parser.
>
>
>??? Will it be possible to use vfp-XSource-tools (for instance import/export wizard) on exabyte layer?
>Answer: Sure the VFP license allows so. The exabyte layer works like if you were using the Fox layer. i.e. REPLACE myField WITH myValue is agnostic of the underlying layer.
>
>
>??? publishing your benchmark code will be a great way to build trust.
>Answer: Well compile this code and let us know. Trick: use memory variables, because the VFP layer trip is slow in the Alpha. You do a VFP layer trip when you wrote ? lnend instead of ? m.lnEnd.
>
>
>Local lnStart, lnCount
>lnStart = Seconds()
>lnCount = 0
>m.lnCount2 = 0
>DO WHILE m.lnCount < 5000000
> m.lnCount = m.lnCount + 1
>ENDDO
>*? m.lnCount
>lnEnd = seconds()
>? lnend
>? SECONDS()-m.lnstart, " für 5.000.000"
>
>
>
>- publishing benchmark code showing areas where performance is the same
> or even slightly worse could enhance trust even more.
>
>- optional static typing enhancing the speed of some areas might relieve me of the need to code some fll's
> This sounds a bit like pyrex for python<g>.GREAT!
>* Answer:
>
>TLOCAL xInfo as System::IO::FileInfo
>
>Gives you strong typing if you want it. If not
>
>LOCAL xInfo
>
>
>Works like usual but of couse slower.
>
>
>
>?? If you have to implement the engine for the exabyte layer yourself, I'ld try to minimize the danger by working only the largest tables first with your compiler. Would it be possible to run a vfp code from the vfp runtime, branch into your .Net extender and from there call up the any vfp-code compiled with your compiler into .Net assemblies
>
>Answer: Sure we already did it and this is a fully supported scenario. If you see at vfp.runtime.dll and vfp.runtime3.dll there is already VFPCompiler - compilated code that we call from .NET Extender.
>
>
> ? This way at first I don't have to veryfy every step, only the things routines working on the exa tables.
>Answer: We think the same way so we first introduce .NET Extender and later the VFPCompiler and we already are using both in the way you figured out.
>
>
>??? This really sounds fascinating - we are currently thinking to move away from dbf to DB2, Postgres or MSSQL mostly for the 2 gig reason later this year. You might give us another option <bg>.
>
>Answer: Well, the 2 gig limit is so small for today multimedia apps, this is one reason we broke it. It seems to us overkill to use a Database Server for only storing big blobs, for that it is better a Table Layer like the one on VFP.
>
>I completely understand the reasons for the disclaimer on your site - perhaps under a similar disclaimer you could tell a bit more about your tool. At least you will get some feedback on what I think is necessary/helpful as soon as I have a clearer picture<bg>.
>
>?? The only drawback is if this really works I won't go as deep into Ironpython to get some dynamic .Net knowledge as I had planned before.
>
>Answer: Well IronPython does not let you create assemblies and it compiles all the source code any time you run it. I like more to only redistribute assemblies, compiled code.
>
>
>regards
>
>thomas