Haha, thanks Kurt, I *think* that was helpful (not quite sure ;). So what you are basically saying is "Yes - pick one of those three options". Have you thought of a career in politics?
Cheers, Phil. ----- Original Message ----- From: "Wilkin, Kurt" <[EMAIL PROTECTED]> To: "NZ Borland Developers Group - Offtopic List" <[EMAIL PROTECTED]> Sent: Friday, November 19, 2004 10:17 AM Subject: RE: [DUG-Offtopic] Java Servletts and PHP processes > > > > > > -----Original Message----- > > > From: Phil Middlemiss [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, 18 November 2004 17:44 > > > To: NZ Borland Developers Group - Offtopic List > > > Subject: [DUG-Offtopic] Java Servletts and PHP processes > > > > > > > > > We are at the design phase of a new web app that will > > consist of a Java > > > applet that is continually fetching data from the server > > (same machine > > that > > > serves the applet and containing page). We are limited at > > the moment to > > > three choices: > > > > > > 1) use a servlet to dish up the data to the applet > > > 2) the applet can fetch a php file off the server which > > will contain the > > > data > > > 3) build our own web server to dish up both the page and the data. > > > > > Hmm, web services... > I'm struggling to remember the details, but I don't believe > php has an instance per web server connection. > I think (you're on Apache, right?) that you do have some control > over exactly how this does work (Apache'll definitely do connection > pooling). > > AFAIK, your 3 options are pretty balanced (php'll be faster, but > applets'll be more consistent with the rest of your java etc), > and suggest that you just maximise (1) your current skills and > (2) where you want your skills to be in the future - ie just pick > the one you like most :) > > > > The build-our-own-Delphi-server option appeals, but we are > > inexperienced > > > with "hardening" a web server and the scaleability issues > > are a little > > > unknown to us also. > > > > > This'd be my least (from a business perspective) liked and > most (from the dev perspective) liked option, but don't be afraid of the > "hardening" bit - it'd be an order of magnitude easier than > hardening IIS or Apache: > - It's Delphi = 0 (Zip, zilch, zero) buffer overflows > - Explicitly block launching *any* external executables > (ie No cmd.exe, no cgi, no perl) > - fine grained user authentication ("You're logging > on from 257.308.432.321 and its 10:27 on Tuesday? You aren't > one of our customers!") > - easy configuration : don't need to allow script access on > these 3 dirs and read access on that one for these 4 sites. > Just pull everything you need in to the server. > - Again : nada, none, nil, buffer overflows (how do c/c++ programmers > ever get to sleep? :) Yeah, okay, you do actually have a > dependence on winsock, but so does everything else. > > - scalability isn't an issue either : IIS / Apache for the > first n years of their existence were optimised for > pushing out static content, so a custom web-app would > thrash either of them for scalablity (speed & size) > > Also, with http components, most of the hard bits are already done. > > Damn, I'll post this, but only cause this is OT list. > My solution basically boils down to pick one of 3 options, > and either write your own web server or not :) > > Cheers, Kurt. > This electronic message together with any attachments is confidential and > intended for the named recipient's use only. If you are not the intended > recipient (i) do not copy, disclose or use the contents in any way, (ii) > please let us know by return email immediately then destroy the message, and > any hard copies of the message, and any attachments. The sender of this > message is not responsible for any changes made to this message and/or any > attachments and/or connection linkages to the Internet referred to in this > message after it has been sent. Unless otherwise stated, any pricing > information given in this message and/or attachments is indicative only, is > subject to change and does not constitute an offer to buy or sell securities > or derivatives at any price quoted. Any reference to the terms of executed > transactions should be treated as preliminary only and subject to separate > formal written notification. Where reference is made to research material > and/or research recommendations, the basis of the provision of such research > material and/or recommendations is set out in the relevant disclaimer. > > _______________________________________________ > Offtopic mailing list > [EMAIL PROTECTED] > http://ns3.123.co.nz/mailman/listinfo/offtopic _______________________________________________ Offtopic mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/offtopic
