Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Amazing foxISAPI observations - this can't be!
Message
 
À
Tous
Information générale
Forum:
Visual FoxPro
Catégorie:
Applications Internet
Titre:
Amazing foxISAPI observations - this can't be!
Divers
Thread ID:
00985861
Message ID:
00985861
Vues:
100
My prototype "internet" project is using foxISAPI and VFP coms (thank you Mr. Strahl!). Later parts of it might move under (or beside) a "commercial" com.

My last intense "html" project was in the 90's. I don't think the technology (or at least my knowledge of it) allowed for client data stores. Now (it seems new to me!) we can "manage" the stores at the client (setting and reading value attributes).

It also means the server does not have to be burdened with all the caching responsibilities!

One suspicion (myth?) I held regarding an IIS/foxISAPI.DLL/VFP COM/Browser architecture was that every time the com was instanced, a vfp runtime would load into memory. That one busted. It didn't happen!

I also thought it would be slow - but its surprisingly fast - even opening opening and closing DBFs was quick as "whatever" - and still - VFP runtime did not show as a process.

I did "load" VFP once - and cannot be sure a localhost can see a "loaded" vfp runtime. But the cgi response seemed somewhat "quicker" - but it could have been wishful thinking. Any feedback on this appreciated.

I was also amazed by the fact that moving the mouse across the IE client ate more CPU than a VFP com method transacting with a DBF.

NO VFP runtimes ever loaded. Who is parenting the my little VFP COM when the url makes a cgi request? I thought runtime needed to be "loaded" to do that.

Thanks
Imagination is more important than knowledge
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform