Well, that's what I'm doing... and you can see the stuff directly served via the HTTP server come up really fast, and the delay in the advertpro picking a b anner.
Until I installed it on my own servers, I couldn't tell if it was AP or the underlying server causing the problems. Now I see that there is a calculational lag in AP. If you look at what it's trying to do to serve a simple banner .... then the JS code wrapped around it. I don't know how to figure any of that into the equations.
I'm wavering as much on this issue as I am on the minivend/interchange vs my own catalog program. FWIW... programs that are more than a year old (the older, the more they suffer) are no where near the code-quality of the newer ones. Why? stability and maturity in both the webserver, perl and http areas.
Many prorams are in desperate need of a complete rewrite, which is why I'm not pushing or griping about the delays with Links. Things have changed so much, that it's possible for someone to come around and in a couple of months rewrite the major features of wwwthreads, UBB or minivend into a cleaner system. They may be missing a few of the more esoteric features, and lots of the legacy/compatibility features, but that is more of a plus than a minus.
The past two weeks have been frustrating for me waiting for Links, and trying to figure out the new layout, and then wavering between existing GPL source programs or writing a whole set of new ones using the GT modules as the base (after all, that is what I need them for, and many of the GT modules are better than what is currently out there).
FWIW, as powerful and complex as IC is, (minivend/interchange) I don't see why it needs to have a sub-server doing things, when pulling the pages directly through a template parser would do similar, and probably better things. The new GT model of allowing functions in template tags almost gets rid of the need for something as behemoth as mv/IC.... and I'm begining to feel the same way about several other programs.
For instance, my postcards program is a fraction of the size, and far more powerful than it's original, simply by using a few calls to DBSQL.pm and using the Links::Template parser.
The logic is cleaner, and more straight forward, and hopefully, for those using Links and GossMail... it will all be the same.
At some point I'm going to have to bite the bullet here, but I've learned the design stage is the most important. The code can (and sometimes does) write itself if it's planned out ahead of time. The biggest things are re-writes or code changes for unforeseen problems or added features.
PUGDOGŪ PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ