Alexei Zakharov wrote: > Anton, > > How many pages do you plan to have in your application? I mean that > Struts is probably too heavy solution for couple of pages (if this is > your case). *IMHO*
I was thinking the same thing, but was going to keep quiet unless someone else spoke up. However, I think the real problem is scope, not the tool (as I figure one simple page done in Struts is the same amount of time as one w/ another technology). Anton, could you give us a brief outline of how you hope to proceed? Right now we're desperate for the basics - somewhere to post info, and somewhere to read a summary across all platforms. geir > > Best Regards, > > 2006/8/2, Anton Luht <[EMAIL PROTECTED]>: >> Hello, >> >> > > I believe that there are more installations that can execute CGI than >> > > those that can run servlets. I'm sure that for the first time the >> test >> > > infrastructure will be deployed to an existing installation but >> not to >> > > a dedicated server - that's why I decided that CGI suites better. >> > >> > But we aren't going to deploy the "central service" to everywhere, just >> > to the apache infrastructure. >> >> I don't know Apache infrastructure too well - ok, if there's a >> possibility to deploy a webapp - I'll write server-side in Java, no >> problem. >> >> If anyone objects that the technology should be Java + servlet >> container, please let community know. If nobody objects I'm going to >> get down to coding. I think I'll use Struts for the app. >> >> > > When we have a dedicated host for builds maybe it'll be worth to >> > > rewrite test infrastructure in Java. But please do not consider the >> > > choice of technology final - I just wanted to pick something that >> fits >> > > for a prototype: fast to develop and easy to deploy. >> > >> > I'm confused. We'll have a host to receive this info from the >> > distributed build machines. One host will be recording the info from >> > the all the other distributed build machines... >> > >> > geir >> > >> > > >> > > On 8/1/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: >> > >> Hi Anton, >> > >> >> > >> > I believe that most >> > >> > common server-side engine is CGI (not PHP or J2EE) so I'd like to >> > >> > implement this using Perl CGI scripts. >> > >> >> > >> (just thinking about) there are several good Java-oriented >> > >> technologies - servlets, JSP, JSF - why not to use them? I don't >> like >> > >> to say that servlets are more frequent than perl, but Java itself is >> > >> not the most widely used language. We should advertise it. :) IMHO >> > >> having Java web/servlets server (not a complete J2EE) for such >> type of >> > >> tasks with theoretically Harmony JRE inside will do a good job >> for our >> > >> project. >> > >> >> > >> Regards, >> > >> >> > >> 2006/7/28, Anton Luht <[EMAIL PROTECTED]>: >> > >> > Hello, >> > >> > >> > >> > I know why this thread is so lazy - it's because everybody >> dislikes QA >> > >> > & testing :) >> > >> > >> > >> > > OK, now let me add my $0.02 about my vision about reporting >> of test >> > >> > > results. I believe it's better to do this using HTTP rather >> than mail >> > >> > > because some people may not have access to SMTP port (for >> example, be >> > >> > > behind proxy with Exchange as mail server - I don't really >> know if it >> > >> > > provides SMTP service). HTTP is open in most configurations >> and it >> > >> > > was already decided that HDK and tests will be delivered via >> HTTP. >> > >> > > >> > >> > > I see the reporting of the results in the following way: after >> > >> > > executing tests the script packs results and uploads them (as >> with >> > >> > > browser file upload) to the server. After that data is >> processed on >> > >> > > server-side - daemons can send periodical e-mails, draw charts, >> > >> > > reports, lists of top test results contributors, etc. >> > >> > >> > >> > Nobody criticized this approach so I assume that it's not too >> bad. I'm >> > >> > going to implement a sketch for server-side bunch of scripts - one >> > >> > that accepts uploads and puts them to a temp directory and >> maybe some >> > >> > simple reports. They won't use any database. I believe that most >> > >> > common server-side engine is CGI (not PHP or J2EE) so I'd like to >> > >> > implement this using Perl CGI scripts. Since this is a first >> draft, >> > >> > I'm not going to use advanced templates language like XSLT. >> Including >> > >> > HTML output in script is bad idea so I'm going to use something >> like >> > >> > HTML::Template [1] for pages generation and CGI::Lite [2] for >> requests >> > >> > handling. >> > >> > >> > >> > Perl is chosen just because it suites well for fast prototyping >> > >> development. >> > >> > >> > >> > If nobody objects, I'm going to start coding. >> > >> > >> > >> > [1] http://html-template.sourceforge.net/ >> > >> > [2] http://search.cpan.org/~smylers/CGI-Lite-2.02/Lite.pm >> > >> > >> > >> > -- >> > >> > Regards, >> > >> > Anton Luht, >> > >> > Intel Middleware Products Division >> > >> > >> > >> > >> --------------------------------------------------------------------- >> > >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > >> > To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> > >> > For additional commands, e-mail: >> [EMAIL PROTECTED] >> > >> > >> > >> > >> > >> >> > >> >> > >> -- >> > >> Alexei Zakharov, >> > >> Intel Middleware Product Division >> > >> >> > >> >> --------------------------------------------------------------------- >> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> > >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> > >> For additional commands, e-mail: >> [EMAIL PROTECTED] >> > >> >> > >> >> > > >> > > >> > >> > --------------------------------------------------------------------- >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> >> -- >> Regards, >> Anton Luht, >> Intel Middleware Products Division >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
