> Sounds like a great idea.
Thanks!
> You could probably improve it by not using an actual browser, but
> by using the browser properties in a standalone application. Here
> me out... I am confident there are some Windows widgets that let
> you easily build you own browser.. which is actually Internet
> Explorer without all of the options.
Oh yeah, I believe you just have to open a WebBrowse OLE object in a
cWin. I'm not having any luck doing it with my ancient, learning-
edition version of Visual C++, but all the how-to's I'm finding make
it SOUND trivial.
Can anyone think of a down-side to this approach?
> If you were to make a more limited browser interface (so that you
> cut out the browser functionality that an application shouldn't
> have "home,forward,back,view source, disable javascript,disable
> cookies,etc, etc, etc"), and then install the "browser"
> application... you could probably make it a standardized .EXE so
> that any user written PHP program would run on it.
... save image, context menu, etc...
Absolutely! You would definitely need to disable that stuff, at
least once the application debugging is complete. Perhaps a
conditional compile on the debugging flag so that those options are
automatically disabled in release code.
> Other than that, you just need to get the web server figured out.
I wouldn't think it would be too hard <knocks wood>. With Apache,
PHP, and MySQL (or others) all being open source, I don't see any
real reason why they couldn't be compiled into one big app. Plus
there's a web full of experts to draw on.
Actually, now that I think about it, it almost sounds like something
that would make a killer commercial app if it weren't for GPL
<winks>. j/k I'm sure an enterprising programmer could do quite
well with it by publishing documentation like Larry Wall or by
selling support like RedHat.
The only thing that strikes me as really sloppy in this is that the
simplest mechanism for the browser OLE to communicate with the server
portion of the app would be via a port. In other words, you'd point
your OLE at 127.0.0.1:X and tell Apache to serve port X, where X is
some free port.
Since ports are basically analagous to global variables, it means
that you could run a browser simultaneously and surf
http://127.0.0.1:X. I don't think there's generally much harm in
such a thing, but it lacks the cleanliness of a real, compiled app.
That also means that port X is occupied while the app is running and
if you simulataneously launch something that wants to use port X, it
will fail. That's not the end of the world, but I do find it
annoying. It would be a bit like buying those tennis shoes with the
air cushions in the heals and then having to get some CO2 cartridges
to keep them pumped up.
Oh also, another downside is that your PHP source would be stored as
plaintext on the client machine. I'm guessing that it would not be
impossible to encrypt/decrypt the pages on-the-fly, but it is another
hassle.
> How hard would it be to customize this "browser application" to
> start and quit apache in tandem with the application.
I don't see that as an issue. If we're running a browser as an OLE,
then you're really just running an .exe we've created. I don't think
it's any real magic to make Windows .exe's spawn child processes on
initiation and slaughter them before exiting.
> Again, agree on a standardized apache config so that there is only
> one site running... which is on local host, you're pretty much set.
Well since I don't think any of us are chomping at the bit to rewrite
Apache, it only makes sense to compile it in! :) Therefore the
config would be according to the standard.
Any nay-sayers out there? Anyone with more Windows programming
experience? I'm far from an expert here!
Gre7g.
=================================================================
Gre7g Luterman [EMAIL PROTECTED] http://www.templeofluna.com/
Stay informed: http://www.templeofluna.com/keeper/mailinglist.htm
Never pet a burning puppy.
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
