Well....true about the apache folks (but I can say for a fact it wasnt a fun or bump free road) . But am I correct in assuming that this is going to be GUI (since thats the name of this list :) .... I am NOT a Java programmer (by any stretch of the imagination) So I guess the 2 code base suggestion was based on what I do know . C, Perl, Tcl, VB Fortran, etc. I do know programming on Nt pretty well (probably all in all better than on *nix anymore) So dev time on the NT platform for me would be less than 1/3 rd of a cross platform solution .NOW , even though I dont code in Java , I do use it from time to time and a tool that will run on both , look the same on both, and address security issues on both would be nice, but it sounds like adding alot to the development cycle when the security issues arent really that similar, apache is a web server , and although can pose a security risk , I would assume a program that can write , kill and start proccess is MUCH more dangerous. Look hee I am discussing security .....sheeze.....Anyway not being that familiar with Java in a personal form , does Java have safegaurds to address the different types of security problems that will be found on both platforms..?
Chris Wertman Gary E. Bickford wrote: > At 5:50 PM -0500 9/9/98, Chris Wertman wrote: > >P.S. Gary, when I say paranoid Im not referring to you , just some general > >feeling Im getting from some of these guys , and after typing this long > >winded > >PUFF , Im too tired to cut and paste it into a new thread....:) > > :) > > I agree there is such a thing as worrying too much. I'm basically thinking > that using the Java RMI, the individual sites can decide which > transport/security mechanism might have to go underneath, if any. Other > than some user authentication and basic cleanliness, the Java layer > probably doesn't have to worry much. > > As far as two code bases, the Apache folk seem to have done a pretty fair > job of using a single codebase for NT and unices, and that's in C. In > Java, if we have to use two codebases, why are we here? I would expect > this to be a test of Redmond's (negative) commitment to playing well with > others. > Gary E. Bickford, [EMAIL PROTECTED] > Sr. Systems Administrator, Connect Schlumberger http://www.connect.slb.com >
